JP6801921B2 - 暗号通信方法、情報処理装置及びプログラム - Google Patents

暗号通信方法、情報処理装置及びプログラム Download PDF

Info

Publication number
JP6801921B2
JP6801921B2 JP2019520297A JP2019520297A JP6801921B2 JP 6801921 B2 JP6801921 B2 JP 6801921B2 JP 2019520297 A JP2019520297 A JP 2019520297A JP 2019520297 A JP2019520297 A JP 2019520297A JP 6801921 B2 JP6801921 B2 JP 6801921B2
Authority
JP
Japan
Prior art keywords
key
public key
common
pub
client
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.)
Active
Application number
JP2019520297A
Other languages
English (en)
Other versions
JPWO2018216749A1 (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.)
NEC Network and System Integration Corp
Original Assignee
NEC Network and System Integration Corp
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 NEC Network and System Integration Corp filed Critical NEC Network and System Integration Corp
Publication of JPWO2018216749A1 publication Critical patent/JPWO2018216749A1/ja
Application granted granted Critical
Publication of JP6801921B2 publication Critical patent/JP6801921B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network 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
    • H04L63/0435—Network 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 wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network 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
    • H04L63/0442—Network 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 wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H04L9/0844—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols with user authentication or key authentication, e.g. ElGamal, MTI, MQV-Menezes-Qu-Vanstone protocol or Diffie-Hellman protocols using implicitly-certified keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures

Landscapes

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

Description

［関連出願についての記載］
本発明は、日本国特許出願：特願２０１７−１０３６１９号（２０１７年５月２５日出願）の優先権主張に基づくものであり、同出願の全記載内容は引用をもって本書に組み込み記載されているものとする。
本発明は、暗号通信方法、情報処理装置及びプログラムに関し、特に、公開鍵暗号方式を用いた暗号通信方法、情報処理装置及びプログラムに関する。
特許文献１に、グループメンバが動的に変化する場合でも安全に同報暗号通信を行なえるという同報暗号通信方法が開示されている。具体的には、プロセスが、認証サーバから秘密鍵Ａで暗号化された会話鍵ａを得て、グループ管理サーバに会話鍵ａを用いて加入を申請すること、グループ管理サーバが、この会話鍵ａを用いてグループ毎に共有鍵暗号ｇ１を暗号化してプロセスに配布することが記載されている。
特許文献２には、信頼性が低いチャットサーバを利用する場合でも、通信の秘密を守ることができるというチャットシステムが開示されている。同文献によると、このチャットシステムの鍵管理サーバは、１又は複数のチャンネルを通じて交わされる通信データを暗号化／復号化する為の各チャンネル固有のチャンネル秘密鍵を作成するチャンネル秘密鍵作成手段を備える。そして、この鍵管理サーバは、このチャンネル秘密鍵を暗号化する暗号化手段と、他の端末装置からチャンネル固有のチャンネル秘密鍵の配送要求を受け付ける受付手段と、この配送要求に応じて端末装置へ暗号化済みのチャンネル秘密鍵を配送する配送手段とを備える、と記載されている。
暗号通信には、大きく共通鍵暗号方式と公開鍵暗号方式の２つに分類される。以下、ユーザＡ〜ユーザＤの４人のユーザで暗号通信を行う場合の例を挙げて説明する。
（１）共通鍵暗号方式（秘密鍵暗号方式）
図２３は、［共通鍵］で暗号通信を実施する場合の手順を示している。この方式では、登場人物全員に共通の鍵を配布して共有する必要があるが、１対ｎの運用が可能であり、また、ユーザＥが途中で増えた場合であっても、ユーザＢが生成した暗号データを、ユーザＥは復号できるという利点がある。一方で、この方式では、オンラインで共通鍵を配布する場合、通信の傍受等に対してのリスク対策が必要になる。オフラインで共通鍵を配布する場合、媒体に鍵を記録し、人手により配布といった方法が採られており、即時性が劣るとされている。また、紛失・盗難等に対してのリスク対策も必要になる。
（２）公開鍵暗号方式（非対称鍵暗号方式）
公開鍵暗号で暗号通信を実現する場合は以下の方法が考えられる。以降、公開鍵暗号で使われる鍵のうち、公開鍵を［Ｐｕｂ］、秘密鍵を［Ｐｒｉ］と記載する。また、ユーザＸの公開鍵及び秘密鍵をそれぞれ［Ｘ．Ｐｕｂ］、［Ｘ．Ｐｒｉ］と記す。
（２−１）送信ユーザの［Ｐｒｉ］で暗号化／送信ユーザの［Ｐｕｂ］で復号を実施
図２４は、データを送信するユーザの鍵を使用して暗号通信を実現する場合の手順を示している。図２４に示すように、データを送信するユーザＡは、送信相手に、自身の公開鍵Ａ．Ｐｕｂを配布する。この方式では、１対ｎの運用が可能であり、また、ユーザＥが途中で増えた場合であっても、ユーザＥはユーザＡの公開鍵を入手できるので、ユーザＡが生成した暗号データを復号できるという利点がある。Ａ．Ｐｕｂは、外部に公開する為の鍵なので、オンラインでの鍵データの配布については、通信の傍受に対してのリスク対策は必要ない。しかしながら、Ｐｒｉで暗号化したデータとセットで傍受された場合には、通信データを復号されてしまうので、やはり通信の傍受に対してのリスク対策が必要となる。また、公開鍵暗号の処理は負荷が高く、高速でのデータ通信や、大容量データの暗号化には不向きである。
（２−２）受信ユーザの［Ｐｕｂ］で暗号化／受信ユーザの［Ｐｒｉ］で復号を実施
図２５、図２６は、データを受信するユーザの鍵を使用して暗号通信を実現する場合の手順を示している。このケースでは、ユーザＡ〜Ｄは、お互いに、［Ｐｕｂ］を配布する。通信データは、送信先（送信相手）の［Ｐｕｂ］で暗号化し、受信ユーザは、自分の［Ｐｒｉ］で復号する。通信データを復号できるのは、［Ｐｒｉ］を持っている自分だけなので、［Ｐｕｂ］と通信データがセットで傍受された場合でも、リスク対策は必要ない。しかしながら、複数のユーザにデータを送ろうとした時は、あて先の各ユーザ毎の［Ｐｕｂ］でそれぞれ暗号化する必要が有り、利便性が劣る。つまり、１対ｎの運用は不可となる。また、この方式では、途中で参加したユーザＥは、ユーザＢから送られたデータを入手したとしても復号することはできない。ユーザＥにもデータを送付したい場合、ユーザＢは、ユーザＥの公開鍵を入手して暗号化しなおす必要がある。また、この方式も（２−１）と同様、公開鍵暗号の処理に要する負荷が高く、高速でのデータ通信や、大容量データの暗号化には不向きである。
（２−３）公開鍵を用いて［共通鍵］を生成し、暗号化／復号を実施
図２７、図２８は、データを送信するユーザと受信するユーザ両方の鍵を使用して暗号通信を実現する場合の手順を示している。図２７に示すように、ユーザＡ〜Ｄがお互いに［Ｐｕｂ］を配布するまでの動作は（２−２）と同様である。この方式では、次式に示すように、ユーザＡ〜Ｄがお互いに、配布された［Ｐｕｂ］と、自分の［Ｐｒｉ］でＤＨ鍵共有を行い、共通鍵暗号の鍵を生成する。なお、ＤＨ鍵共有とは、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ ｋｅｙ ｅｘｃｈａｎｇｅの略であり、通信を行いたい２者が、互いに公開鍵のみを相手に送信し、各自、自分の秘密鍵と受信した公開鍵から共通鍵を作成する方法である。なお、ＤＨ鍵共有は、
ユーザＡ ： 鍵共有（［Ａ．Ｐｒｉ］ 、 ［Ｂ．Ｐｕｂ］ ） → ［共通鍵］
ユーザＢ ： 鍵共有（［Ｂ．Ｐｒｉ］ 、 ［Ａ．Ｐｕｂ］ ） → ［共通鍵］
なお、図２８において、「ＸＹ共通鍵」はＸＹ間の通信においてＸが使用（暗号化および複号）する共通鍵を示し、同じＸＹ間の通信でＹが使用（暗号化および複号）する共通鍵は「ＹＸ共通鍵」と示す。
このように、共通鍵暗号で通信データを暗号化するハイブリッド方式を採用することで、常時通信データを暗号化する際のリソース消費の問題を解決できる。また、ＤＨ鍵共有を行うことで、他者が復号できない安全な通信を実現できる。ただし、本方式においても、１対多の通信を実現しようとすると、総当りで１対１通信を行う事になり、利便性が劣る。また、第三者攻撃に対してのリスクが残る。
特開平７−６６８０３号公報 特開２００５−３９８６８号公報
以下の分析は、本発明によって与えられたものである。上記（２−３）の公開鍵を用いて［共通鍵］を生成し、暗号化／復号を実施する方法に、署名用の鍵を追加して実現することが考えられる。
具体的には、次式に示すプロトコルとなる。
認証局：署名付与（［Ａ．Ｐｕｂ］、［認証局．証明Ｐｒｉ］）
認証局：署名付与（［Ｂ．Ｐｕｂ］、［認証局．証明Ｐｒｉ］）

ユーザＡ：署名検証（［Ｂ．Ｐｕｂ］、［認証局．証明Ｐｕｂ］）→［Ｂ．Ｐｕｂ］は正規
ユーザＡ：鍵共有（［Ａ．Ｐｒｉ］、［Ｂ．Ｐｕｂ］）→［共通鍵］

ユーザＢ：署名検証（［Ａ．Ｐｕｂ］、［認証局．証明Ｐｕｂ］）→［Ａ．Ｐｕｂ］は正規
ユーザＢ：鍵共有（［Ｂ．Ｐｒｉ］、［Ａ．Ｐｕｂ］）→［共通鍵］
上記プロトコルにおいて、署名付与（Ｘ、Ｙ）は、公開鍵Ｘに、秘密鍵Ｙを用いた署名を付すことを示している。また、署名検証（Ｘ、Ｙ）は、公開鍵Ｙを用いて公開鍵Ｘの正当性（署名）を検証することを示している。また、鍵共有（Ｘ、Ｙ）→［共通鍵］は、秘密鍵Ｘと、通信相手の公開鍵Ｙを用いて共通鍵を作成することを示している。
上記のように、認証局（外部機関）を用意し、認証局が署名を付与する為の［証明鍵］を追加することにより、お互いが本人であることを証明できる様になるので、第三者攻撃に対してのリスクが消える。しかしながら、上記変更を加えたとしても（２−３）の方法では、総当りで１対１通信を行うことは変わらず、利便性が劣ったままとなるという問題点がある。
本発明は、通信データを暗号化する際のリソース消費の問題と、ユーザの利便性の向上の両立に貢献できる暗号通信方法、情報処理装置及びプログラムを提供することを目的とする。
第１の視点によれば、（Ａ）２以上の端末がそれぞれ第１の公開鍵と第１の秘密鍵の組を準備するステップを含む暗号通信方法が提供される。この暗号通信方法は、さらに、（Ｂ）前記２以上の端末のうち一の端末が第２の公開鍵と第２の秘密鍵の組を作成し、他の端末に配布するステップを含む。この暗号通信方法は、さらに、（Ｃ）前記２以上の端末のうち一の端末が、前記（Ａ）で準備した第１の秘密鍵と、前記（Ｂ）で共有した第２の公開鍵とを用いて、共通鍵を作成するステップを含む。この暗号通信方法は、さらに、（Ｄ）前記２以上の端末のうち他の端末が、前記（Ｂ）で共有した第２の秘密鍵と、前記（Ａ）で準備した前記一の端末の第１の公開鍵とを用いて、前記一の端末との通信に用いる共通鍵を作成するステップを含む。この暗号通信方法は、さらに、（Ｅ）前記端末の組が、前記共通鍵を用いて、暗号通信を実施するステップを含む。本方法は、暗号通信を実施するプロセッサとメモリを備えた情報処理装置という、特定の機械に結びつけられている。
第２の視点によれば、上記した暗号通信方法を実施できる端末として機能する情報処理装置が提供される。
第３の視点によれば、上記した暗号通信方法に用いるサーバが提供される。
第４の視点によれば、情報処理装置に、上記した暗号通信方法を実施させるためのコンピュータプログラムが提供される。なお、このプログラムは、コンピュータが読み取り可能な（非トランジエントな）記憶媒体に記録することができる。即ち、本発明は、コンピュータプログラム製品として具現することも可能である。
本発明によれば、通信データを暗号化する際のリソース消費の問題と、ユーザの利便性の向上を両立させることが可能となる。即ち、本発明は、背景技術に記載したハイブリッド方式の暗号通信を行う機器を、その利便性を向上させたものへと変換するものとなっている。
本発明の暗号通信方法の手順を示す図である。 図１の続図である。 本発明が適用されるチャットシステムの構成を示す図である。 図３のチャットシステムにより提供される会話空間（チャットルーム）を説明するための図である。 本発明の第１の実施形態のチャットシステムの物理的構成を説明するための図である。 本発明の第１の実施形態のチャットシステムのソフトウェア構成を説明するための図である。 本発明の第１の実施形態の動作（クライアント登録）を説明するための図である。 本発明の第１の実施形態の動作（送信鍵の作成）を説明するための図である。 本発明の第１の実施形態の動作（部屋の作成）を説明するための図である。 本発明の第１の実施形態の動作（参加−１）を説明するための図である。 本発明の第１の実施形態の動作（参加−２）を説明するための図である。 本発明の第１の実施形態の動作（参加−３）を説明するための図である。 本発明の第１の実施形態の動作（チャット）を説明するための図である。 本発明の第１の実施形態の動作（途中参加−１）を説明するための図である。 本発明の第１の実施形態の動作（途中参加−２）を説明するための図である。 本発明の第１の実施形態の動作（途中参加−３）を説明するための図である。 本発明の第１の実施形態の動作（途中参加−４）を説明するための図である。 本発明の第１の実施形態の動作（過去ログ閲覧）を説明するための図である。 本発明の第１の実施形態の動作（チャット）を説明するための図である。 本発明の第２の実施形態の暗号通信システムの構成を示す図である。 本発明の第２の実施形態の暗号通信システムの物理的構成を説明するための図である。 本発明の第２の実施形態の暗号通信システムのソフトウェア構成を説明するための図である。 共通鍵で暗号通信を実施する場合の手順を示す図である。 公開鍵で暗号通信を実施（送信者の秘密鍵で暗号化）する場合の手順を示す図である。 公開鍵で暗号通信を実施（受信者の公開鍵で暗号化）する場合の手順を示す図である。 公開鍵で暗号通信を実施（受信者の公開鍵で暗号化）する場合の手順を示す図である。 公開鍵で暗号通信を実施（ＤＨ鍵交換を利用）する場合の手順を示す図である。 公開鍵で暗号通信を実施（ＤＨ鍵交換を利用）する場合の手順を示す図である。 本発明の情報処理装置を構成するコンピュータの構成を示す図である。
はじめに本発明の一実施形態の概要について図面を参照して説明する。なお、この概要に付記した図面参照符号は、理解を助けるための一例として各要素に便宜上付記したものであり、本発明を図示の態様に限定することを意図するものではない。また、以降の説明で参照する図面等のブロック間の接続線は、双方向及び単方向の双方を含む。一方向矢印については、主たる信号（データ）の流れを模式的に示すものであり、双方向性を排除するものではない。また、図中の各ブロックの入出力の接続点には、ポート乃至インタフェースがあるが図示省略する。
本発明は、その一実施形態において、図１、図２に示すように、複数のユーザが参加する１対ｎの暗号通信方法（ｎは１以上）として実現できる。まず、図１に示すように、鍵情報の配布が行われる。まず、（Ａ）複数のユーザＡ〜Ｄが、それぞれの端末に、送信用公開鍵（Ｘ．送信Ｐｕｂ）及び送信用秘密鍵（Ｘ．送信Ｐｒｉ）を準備する。なお、送信用公開鍵（Ｘ．送信Ｐｕｂ）及び送信用秘密鍵（Ｘ．送信Ｐｒｉ）が、第１の公開鍵と第１の秘密鍵の組に相当する。
さらに、（Ｂ１）ユーザＡ〜Ｄのうちの任意のユーザ（図１のユーザＡ）が、受信用公開鍵（Ａ．受信Ｐｕｂ）及び受信用秘密鍵（Ａ．受信Ｐｒｉ）を作成する（図１の「（１）鍵を作成」参照）。なお、受信用公開鍵（Ａ．受信Ｐｕｂ）及び受信用秘密鍵（Ａ．受信Ｐｒｉ）が、第２の公開鍵と第１の秘密鍵の組に相当する。
次に、ユーザＡ〜Ｄは、それぞれの送信用公開鍵（Ｘ．送信Ｐｕｂ）を自分以外のユーザに配布する。さらに、（Ｂ２）前記受信用公開鍵（Ａ．受信Ｐｕｂ）及び受信用秘密鍵（Ａ．受信Ｐｒｉ）を作成したユーザ（図１のユーザＡ）は、作成した受信用公開鍵（Ａ．受信Ｐｕｂ）及び受信用秘密鍵（Ａ．受信Ｐｒｉ）を他のユーザに配布する。なお、ここでの鍵の配送手段としては、背景技術として説明した各種の鍵配送手段を用いることができる。以上の結果、それぞれのユーザは、あるユーザが作成した受信用公開鍵と秘密鍵（Ａ．受信Ｐｕｂ、Ａ．受信Ｐｒｉ）の組と、自分以外のユーザの送信用公開鍵（Ｘ．送信Ｐｕｂ）を保持した状態になる（図１の「（２）鍵を配布」参照）。
以上の準備が完了すると、図２に示す共通鍵の作成と暗号通信を実施可能となる。（Ｃ）まず、ユーザＡ〜Ｄのうちの任意のユーザ（図２のユーザＢ）が、前記（Ａ）で準備した自身の送信用秘密鍵（Ｂ．送信Ｐｒｉ）と、（Ｂ２）で共有した受信用公開鍵（Ａ．受信Ｐｕｂ）とを用いて、Ｂ．送信用共通鍵を作成する。（Ｄ）同様に、他のユーザは、前記（Ｂ１）、（Ｂ２）で共有した受信用秘密鍵（Ａ．受信Ｐｒｉ）と、ユーザＢの送信用公開鍵（Ｂ．送信Ｐｕｂ）とを用いて、ユーザＢとの通信に用いるＢ．受信用共通鍵を作成する。以上により、ユーザＢ−ユーザＡ、ユーザＢ−ユーザＣ、ユーザＢ−ユーザＤ間の共通鍵が共有されたことになる（図２の（３）鍵共有）。
以降、ユーザＢ−ユーザＡ、ユーザＢ−ユーザＣ、ユーザＢ−ユーザＤ間で、前記送信用共通鍵と前記受信用共通鍵を用いて、暗号通信を実施することが可能となる。例えば、図２の下段に示すように、ユーザＢは、平文データをＢ．送信用共通鍵で暗号化して、ユーザＡ、Ｃ、Ｄに送信する。ユーザＡ、Ｃ、Ｄは、ユーザＢから受信した暗号データを、Ｂ．受信用共通鍵で復号し、ユーザＢが作成した復号データ（平文データ）を得ることができる。
以上説明したように、本発明によれば、公開鍵暗号と共有鍵暗号のハイブリッド方式を採用した暗号通信が実現される。特に本発明では図２の（３）のユーザＢに代表されるように、ユーザは、データを暗号化する際、復号者の鍵を意識せずに処理できる様になっている。このため、本発明は、複数のユーザに対してデータを暗号化して送りたい時に、ユーザ毎に異なる暗号化を実施せずに済むという利点がある（図２５〜図２８の方式に対する優位性）。
また、上記の点は、後から参加してきたユーザが、受信用公開鍵と受信用秘密鍵の組を入手することで、既に暗号化済みのデータを復号できることを意味する。このため、本発明は、時間的に隔絶した特定の２者間での秘密情報の授受にも適用できる。この点については、後に第２の実施形態として説明する。
［第１の実施形態］
本発明をＩＲＣ（Ｉｎｔｅｒｎｅｔ Ｒｅｌａｙ Ｃｈａｔ）システムに適用した実施形態の前に、プロトコルの骨子を説明する。本発明は、認証局と連携させることでより好適に実施可能である。本実施形態では、上述の［受信鍵］、［送信鍵］に加えて、［証明鍵］、［認証鍵］が準備される。はじめに、これらの鍵について説明する。
［証明鍵］、［認証鍵］、［受信鍵］、［送信鍵］・・・これらの鍵にはそれぞれ公開鍵（Ｐｕｂ）、秘密鍵（Ｐｒｉ）が存在する。
［証明鍵Ｐｕｂ］、［証明鍵Ｐｒｉ］は、ルート認証局（ルートＣＡ）の鍵として位置づけられ、認証局は、証明鍵Ｐｒｉを用いて、必要なデータに署名を付与する。
［認証鍵Ｐｕｂ］、［認証鍵Ｐｒｉ］は、ルート認証局（ルートＣＡ）の下位の認証局である中間認証局（中間ＣＡ）の鍵として位置づけられ、各ユーザが作成し保持する。［認証鍵Ｐｕｂ］は、認証局の［証明鍵Ｐｒｉ］で署名される。
［受信鍵Ｐｕｂ］、［受信鍵Ｐｒｉ］のうち［受信鍵Ｐｒｉ］は、データを復号するために使用する。［受信鍵Ｐｕｂ］、［受信鍵Ｐｒｉ］の組は、代表者が作成し、そのユーザの［認証鍵］で署名されて、他のユーザに配布される。
［送信鍵Ｐｕｂ］、［送信鍵Ｐｒｉ］のうち［送信鍵Ｐｒｉ］は、データを暗号化する為に使用する。［送信鍵Ｐｕｂ］、［送信鍵Ｐｒｉ］の組は、各ユーザが作成し、このうち、［送信鍵Ｐｕｂ］は、各ユーザの［認証鍵］で署名されて、他のユーザに配布される。
鍵の配送は以下のように行われる。以下、ユーザＡ、Ｂ間の配送を例に説明する。なお、以下の説明において、署名付与（Ｘ、Ｙ）は、公開鍵Ｘに、秘密鍵Ｙを用いた署名を付すことを示している。また、署名検証（Ｘ、Ｙ）は、公開鍵Ｙを用いて公開鍵Ｘの正当性（署名）を検証することを示している。また、鍵共有（Ｘ、Ｙ）→［共通鍵］は、秘密鍵Ｘと、通信相手の公開鍵Ｙを用いて共通鍵を作成することを示している。
（１）まず、認証局が、ユーザＡ、Ｂの認証公開鍵の正当性を証明する公開鍵証明書を発行する。
認証局：署名付与（［Ａ．認証Ｐｕｂ］、［認証局．証明Ｐｒｉ］）
認証局：署名付与（［Ｂ．認証Ｐｕｂ］、［認証局．証明Ｐｒｉ］）
（２）ユーザＡは、自身の認証秘密鍵を用いて、受信公開鍵及び送信公開鍵に署名を付与してユーザＢに送る。また、ユーザＡは、ユーザＢの認証公開鍵を、認証局の証明公開鍵で検証し、その正当性を確認する。また、ユーザＡは、ユーザＢの送信公開鍵を、ユーザＢの認証公開鍵で検証し、その正当性を確認する。
ユーザＡ：署名付与（［Ａ．受信Ｐｕｂ］、［Ａ．認証Ｐｒｉ］）
ユーザＡ：署名付与（［Ａ．送信Ｐｕｂ］、［Ａ．認証Ｐｒｉ］）
ユーザＡ：署名検証（［Ｂ．認証Ｐｕｂ］、［認証局．証明Ｐｕｂ］）
→［Ｂ．認証Ｐｕｂ］は正規
ユーザＡ：署名検証（［Ｂ．送信Ｐｕｂ］、［Ｂ．認証Ｐｕｂ］）
→［Ｂ．送信Ｐｕｂ］は正規
（３）同様に、ユーザＢは、自身の認証秘密鍵を用いて、送信公開鍵に署名を付与してユーザＡに送る。また、ユーザＢは、ユーザＡの認証公開鍵を、認証局の証明公開鍵で検証し、その正当性を確認する。また、ユーザＢは、ユーザＡの受信公開鍵及び送信公開鍵を、ユーザＡの認証公開鍵で検証し、その正当性を確認する。
ユーザＢ：署名付与（［Ｂ．送信Ｐｕｂ］、［Ｂ．認証Ｐｒｉ］）
ユーザＢ：署名検証（［Ａ．認証Ｐｕｂ］、［認証局．証明Ｐｕｂ］）
→［Ａ．認証Ｐｕｂ］は正規
ユーザＢ：署名検証（［Ａ．受信Ｐｕｂ］、［Ａ．認証Ｐｕｂ］）
→［Ａ．受信Ｐｕｂ］は正規
ユーザＢ：署名検証（［Ａ．送信Ｐｕｂ］、［Ａ．認証Ｐｕｂ］）
→ ［Ａ．送信Ｐｕｂ］は正規
（４）以上のように認証用公開鍵と秘密鍵を用意し、認証局の証明を得ておくことで以降、ユーザは、自分が生成した［受信鍵］／［送信鍵］への署名付与を自分だけで実施できるようになる。例えば、ユーザＡは生成した［Ａ．受信鍵Ｐｕｂ］の署名付与（［Ａ．受信鍵Ｐｕｂ］、［Ａ．認証Ｐｒｉ］）により、認証局に依頼せずに、自分で署名付与を行い、ユーザＢに送ることができる。このように、本実施形態では、［受信鍵］／［送信鍵］の更新（生成）の頻度に対して、認証局への署名付与作業の依頼の頻度を軽減し、かつ、ユーザの利便性を向上させることが可能となっている。
続けて、ユーザ間で共有した［受信鍵］（第２の公開鍵と第２の秘密鍵の組）と、ユーザ個別で専有する［送信鍵］（第１の公開鍵と第１の秘密鍵の組）で、鍵共有を行い、共通鍵暗号に使用する共通鍵を生成する。例えば、ユーザＡ、ユーザＢ、ユーザＣの三者で共通鍵を作成する場合は、各ユーザがそれぞれ３つの共通鍵を作成することになる。
ユーザＡ：鍵共有（［Ａ．送信鍵Ｐｒｉ］、［受信鍵Ｐｕｂ］）→Ａ送信用共通鍵（Ｓ）
ユーザＡ：鍵共有（［受信鍵Ｐｒｉ］、［Ｂ．送信鍵Ｐｕｂ］）→Ｂ受信用共通鍵
ユーザＡ：鍵共有（［受信鍵Ｐｒｉ］、［Ｃ．送信鍵Ｐｕｂ］）→Ｃ受信用共通鍵
ユーザＢ：鍵共有（［Ｂ．送信鍵Ｐｒｉ］、［受信鍵Ｐｕｂ］）→Ｂ送信用共通鍵
ユーザＢ：鍵共有（［受信鍵Ｐｒｉ］、［Ａ．送信鍵Ｐｕｂ］）→Ａ受信用共通鍵（Ｔ）
ユーザＢ：鍵共有（［受信鍵Ｐｒｉ］、［Ｃ．送信鍵Ｐｕｂ］）→Ｃ受信用共通鍵
ユーザＣ：鍵共有（［Ｃ．送信鍵Ｐｒｉ］、［受信鍵Ｐｕｂ］）→Ｃ送信用共通鍵
ユーザＣ：鍵共有（［受信鍵Ｐｒｉ］、［Ａ．送信鍵Ｐｕｂ］）→Ａ受信用共通鍵（Ｕ）
ユーザＣ：鍵共有（［受信鍵Ｐｒｉ］、［Ｂ．送信鍵Ｐｕｂ］）→Ｂ受信用共通鍵
このとき、ユーザＡが（Ｓ）の鍵で暗号化したデータを、ユーザＢ、Ｃは、それぞれ（Ｔ）、（Ｕ）で復号できる。この時、ユーザＡは、（Ｓ）の鍵を生成する際に、自分の持っている鍵しか使用しない。
従って、本実施形態では、各ユーザは、自分が持っている鍵のみを使用して、送信用共通鍵を生成できるので、他者（復号する者）を意識せずに、データを暗号化することができるようになる。また、これにより、総当りで１対１通信を行う必要が無くなるので、ユーザの利便性も向上させることができる（図１、図２参照）。
［ＩＲＣシステム］
続いて、本発明をＩＲＣ方式のＣＨＡＴシステムに適用する場合の具体例について説明する。ＩＲＣ（Ｉｎｔｅｒｎｅｔ Ｒｅｌａｙ Ｃｈａｔ）とは、サーバを介してクライアント間で多対多の会話をする、クライアント／サーバ型のシステムとして構成される。
図３は、本発明の適用対象とするチャットシステムの構成を示す図である。図３を参照すると、互いに接続された複数のＩＲＣサーバ２０−Ａ〜２０−Ｄと、これらＩＲＣサーバ２０−Ａ〜２０−Ｄのいずれかに接続して他のＩＲＣクライアントと会話をするＩＲＣクライアント１０−１〜１０−６とが示されている。
ＩＲＣサーバ２０−Ａ〜２０−Ｄは、ＩＲＣクライアント１０−１〜１０−６からは１つのＩＲＣサーバとして見える。図４は、図３のチャットシステムにより提供される会話空間（チャットルーム）を説明するための図である。図４に示すように、ＩＲＣサーバ２０（以下、ＩＲＣサーバ２０−Ａ〜２０−Ｄを特に区別しない場合、「ＩＲＣサーバ２０」と記す。）は部屋（チャットルーム）と呼ばれる会話空間を提供し、ＩＲＣクライアント１０−１〜１０−６は、所望の部屋に入り、その部屋の中で、会話を行う。例えば、図４に示すように、ある部屋にいるＩＲＣクライアント１０−１の発言は、ＩＲＣサーバ２０により、その部屋に在室しているＩＲＣクライアント１０−３とＩＲＣクライアント１０−５に転送される。
本実施形態では、この部屋でやり取りされる発話内容の秘匿化を実現する。図５は、本実施形態のチャットシステムの物理的構成を示す図である。図５に示したとおり、本実施形態では、ＩＲＣサーバ２０と、ＩＲＣクライアントが動作する情報処理装置（端末）１００−１、１００−２に加えて、認証サーバ３０が追加されている。また、ＩＲＣクライアント１０−１、１０−２には、図３、図４に示したチャット機能を実現するＩＲＣ処理部１１に加えて、ＩＲＣが送受信するメッセージの暗復号を行う暗復号処理部１２が追加されている。基本的なメッセージの流れは、以下の通りとなる。あるＩＲＣクライアントのユーザが、テキスト入力や発話等により発言を行うと、ＩＲＣ処理部１１は、暗復号処理部１２に発言内容を送る。暗復号処理部１２は、発言内容を暗号化し、ＩＲＣ処理部１１に返す。ＩＲＣ処理部１１は暗号化されたデータをＩＲＣサーバ２０に送る。ＩＲＣサーバ２０は、受信した暗号化データを他のＩＲＣクライアントに送る。ＩＲＣクライアントは、暗復号処理部１２を用いて、ＩＲＣサーバ２０から受信したデータを復号し、ユーザに提示する。
図６は、本実施形態のチャットシステムのソフトウェア構成を説明するための図である。ＩＲＣサーバ２０のＩＲＣ機能及びＩＲＣクライアント１０−１、１０−２のＩＲＣ機能（上記ＩＲＣ処理部１１に相当）は、図３、図４に示したＩＲＣクライアント／サーバが備えているものである。図６のＩＲＣクライアント１０−１、１０−２の暗号機能は、上記暗復号処理部１２に相当し、認証サーバ３０や他のＩＲＣクライアントとの暗号鍵の授受を行い、最終的には共通鍵を作成して、ＩＲＣでやり取りするメッセージの暗復号を実施する（後に詳説）。なお、図５の例では、説明を簡単にするため、２台のＩＲＣクライアントを示しているが、当然に、ＩＲＣクライアントの数は３以上であってもよい。以下、ＩＲＣクライアントを特に区別しない場合、ＩＲＣクライアント１０と記す。
続いて、上記のＩＲＣクライアント１０、ＩＲＣサーバ２０及び認証サーバ３０によりＣＨＡＴを実施するまでの動作について説明する。なお、以下の説明では、ＩＲＣサーバ２０及び認証サーバ３０を併せて「Ａ．サーバ」と記す。また、ＩＲＣクライアントは３台あるものとし、それぞれを「Ｂ．クライアント」、「Ｃ．クライアント」、「Ｄ．クライアント」と記す。また、図７〜図１９のテーブルの上段は、各エンティティが保持する情報や部屋を示し、下段がそれぞれのエンティティによる処理を示している。また、各エンティティが保持する情報は、ユーザ名．（鍵名）＋Ｐｕｂ／Ｐｒｉの区分を基本とする。また、各エンティティが保持する情報に、「＠」が付されている場合、「＠」以下に記された鍵で作成された署名が付されているものとする。例えば、Ｂ．認証鍵Ｐｕｂ＠Ａ．証明鍵Ｐｒｉは、Ａ．証明鍵Ｐｒｉで作成された署名が付されたＢ．クライアントの認証用公開鍵を意味する。
はじめに、クライアントが部屋に入室してチャットを開始するまでの流れを説明する。以下の説明において、部屋を生成したユーザが、受信鍵を生成するものとした。また、受信鍵のライフタイムは、部屋が生成されてから消滅する迄の間とした。送信鍵のライフタイムは、ユーザが部屋に入ってから退室する迄の間とした。即ち、あるユーザが、部屋に入り直した場合は、送信鍵は更新され、再度ユーザ間で交換することになる。
図７は、本発明の第１の実施形態の動作（クライアント登録）を説明するための図である。図７を参照すると、Ｂ．クライアントが、自身の認証鍵（認証鍵Ｐｒｉと認証鍵Ｐｕｂ）を作成し（ステップＳ００１）、Ａ．サーバに対し、生成した認証鍵Ｐｕｂを送る（ステップＳ００２）。
まず、Ａ．サーバは、何らかの手段（例えば、パスワード、生体情報等）でＢ．クライアントの正当性を確認した上で、証明鍵Ｐｒｉを用いてクライアントの認証鍵Ｐｕｂに署名をつける（ステップＳ００３）。Ａ．サーバは、Ｂ．クライアントに対して署名を付与した認証鍵Ｐｕｂを返却する（ステップＳ００４）。
Ｂ．クライアントは、サーバから受信した署名付きの認証鍵Ｐｕｂを、サーバの証明鍵Ｐｕｂで検証する（Ｓ００５）。以上の動作を、Ｃ．クライアント及びＤ．クライアントも実施して、署名付きの認証鍵Ｐｕｂを入手する（順序はいずれのクライアントが先でも良い）。
図８は、本発明の第１の実施形態の動作（送信鍵の作成）を説明するための図である。図８を参照すると、まず、一番最初に入室したＢ．クライアントが、送信鍵（送信鍵Ｐｒｉと送信鍵Ｐｕｂ）を作成する（ステップＳ１０１）。Ｂ．クライアントは、作成した送信鍵Ｐｕｂに対して、認証鍵Ｐｒｉを用いて署名を付与する（ステップＳ１０２）。Ｃ．クライアント及びＤ．クライアントも同様に、送信鍵（送信鍵Ｐｒｉと送信鍵Ｐｕｂ）を作成し、送信鍵Ｐｕｂに、自身の認証鍵Ｐｒｉを用いて署名を付与する。これにより図９の上段に示すように、各クライアントが、送信鍵Ｐｒｉと署名付きの送信鍵Ｐｕｂを用意した状態となる。
図９は、本発明の第１の実施形態の動作（部屋の作成）を説明するための図である。図９を参照すると、部屋を生成しようとしているＢ．クライアント（親）が受信鍵（受信Ｐｒｉと受信Ｐｕｂ）を作成する（ステップＳ２０１）。
Ｂ．クライアントは、作成した受信鍵Ｐｕｂに対して、認証鍵Ｐｒｉを用いて署名を付与する（ステップＳ２０２）。次に、Ｂ．クライアントは、自身のＢ．送信鍵Ｐｒｉと、受信鍵Ｐｕｂとを用いてＤＨ共通鍵を作成する（ステップＳ２０３）。このＤＨ共通鍵は、Ｂ．クライアント（親）が発言するメッセージを暗号化する際に使用される。以下、ＤＨ共通鍵は、送信鍵Ｐｒｉ×受信鍵Ｐｕｂ等と記す。
ＤＨ共通鍵を作成したＢ．クライアントは、ＩＲＣサーバに部屋作成コマンドを送信する（ステップＳ２０４）。Ａ．サーバ（ＩＲＣサーバ）は、部屋作成コマンドに基づいて部屋を作成する（ステップＳ２０５）。このステップＳ２０４、Ｓ２０５の処理はＩＲＣプロトコルで行われる。以降、Ｂ．クライアントは部屋を作成したユーザであるので、Ｂ．クライアント（親）と記す。
図１０は、本発明の第１の実施形態の動作（Ｃ．クライアントの参加−１）を説明するための図である。図１０を参照すると、Ｃ．クライアント（子）が、Ｂ．クライアント（親）に対し、認証局の署名の付いたＣ．認証鍵Ｐｕｂを送信する（ステップＳ３０１）。Ｂ．クライアント（親）は、Ｃ．認証鍵Ｐｕｂを認証局の証明鍵Ｐｕｂで検証する（ステップＳ３０２）。
Ｃ．認証鍵Ｐｕｂの検証に成功すると、Ｂ．クライアント（親）は、Ｃ．クライアント（子）に対し、認証局の署名の付いたＢ．認証鍵Ｐｕｂと、自身のＢ．認証鍵Ｐｒｉで作成した署名を付けた受信鍵Ｐｕｂと、受信鍵Ｐｒｉを送信する（ステップＳ３０３）。Ｃ．クライアント（子）は、Ｂ．認証鍵Ｐｕｂを認証局の証明鍵Ｐｕｂで検証する（ステップＳ３０４）。
Ｂ．認証鍵Ｐｕｂの検証に成功すると、Ｃ．クライアント（子）は、Ｂ．クライアント（親）の署名付きの受信鍵Ｐｕｂを、Ｂ．クライアント（親）の認証鍵Ｐｕｂで検証する（ステップＳ３０５）。受信鍵Ｐｕｂの検証に成功すると、Ｃ．クライアント（子）は、自身のＣ．送信鍵Ｐｒｉと受信鍵Ｐｕｂとを用いてＤＨ共通鍵（送信用共通鍵）を作成する（ステップＳ３０６）。このＤＨ共通鍵は、Ｃ．クライアント（子）が発言するメッセージを暗号化する際に使用される。
図１１は、図１０の続図である。図１１を参照すると、ＤＨ共通鍵（送信用共通鍵）の作成を終えたＣ．クライアント（子）は、Ｂ．クライアント（親）に対し、認証局の署名の付いたＣ．認証鍵Ｐｕｂ及び自身のＣ．認証鍵Ｐｒｉで作成した署名を付けたＣ．送信鍵Ｐｕｂを送信する（ステップＳ４０１）。Ｂ．クライアント（親）は、Ｃ．認証鍵Ｐｕｂを認証局の証明鍵Ｐｕｂで検証する（ステップＳ４０２）。
Ｃ．認証鍵Ｐｕｂの検証に成功すると、Ｂ．クライアント（親）は、Ｃ．送信鍵Ｐｕｂを、Ｃ．クライアントのＣ．認証鍵Ｐｕｂで検証する（ステップＳ４０３）。Ｃ．送信鍵Ｐｕｂの検証に成功すると、Ｂ．クライアント（親）は、受信鍵ＰｒｉとＣ．送信鍵Ｐｕｂとを用いてＤＨ共通鍵（受信用共通鍵）を作成する（ステップＳ４０４）。このＤＨ共通鍵は、Ｂ．クライアント（親）がＣ．クライアント（子）から受信したメッセージを復号する際に使用される。
ＤＨ共通鍵（受信用共通鍵）の作成を終えたＢ．クライアント（親）は、Ｃ．クライアント（子）に対し、認証局の署名の付いたＢ．認証鍵Ｐｕｂ及び自身のＢ．認証鍵Ｐｒｉで作成した署名を付けたＢ．送信鍵Ｐｕｂを送信する（ステップＳ４０５）。Ｃ．クライアント（子）は、Ｂ．認証鍵Ｐｕｂを認証局の証明鍵Ｐｕｂで検証する（ステップＳ４０６）。
図１２は、図１１の続図である。図１２を参照すると、Ｂ．認証鍵Ｐｕｂの検証に成功すると、Ｃ．クライアント（子）は、Ｂ．送信鍵Ｐｕｂを、Ｂ．クライアント（親）のＢ．認証鍵Ｐｕｂで検証する（ステップＳ５０１）。Ｂ．送信鍵Ｐｕｂの検証に成功すると、Ｃ．クライアント（子）は、受信鍵Ｐｒｉと自身のＢ．送信鍵Ｐｕｂとを用いてＤＨ共通鍵（受信用共通鍵）を作成する（ステップＳ５０２）。このＤＨ共通鍵は、Ｃ．クライアント（子）がＢ．クライアント（親）から受信したメッセージを復号する際に使用される。
以上により、Ｂ．クライアント（親）とＣ．クライアント（子）間でそれぞれ暗号通信に用いる共通鍵が配送された状態となる。図１３は、本発明の第１の実施形態の動作（チャット）を説明するための図である。図１３を参照すると、Ｂ．クライアント（親）はユーザから入力されたチャットメッセージを、ステップＳ２０３で作成した送信用のＤＨ共通鍵（ＤＨ送信鍵）で暗号化し（ステップＳ６０１）、サーバ（ＩＲＣサーバ）に暗号化したチャットメッセージを送信する（ステップＳ６０２）。
サーバ（ＩＲＣサーバ）は、暗号化されたチャットメッセージをログに保存した上で（ステップＳ６０３）、同じ部屋に在室しているＣ．クライアントに、暗号化されたチャットメッセージを送信する（ステップＳ６０４）。図１３に記したように、このステップＳ６０２〜Ｓ６０４の処理はＩＲＣプロトコルで行われる。
前記暗号化されたチャットメッセージを受信したＣ．クライアントは、ステップＳ５０２で作成した受信用のＤＨ共通鍵（ＤＨ受信鍵）で、暗号化されたチャットメッセージを復号する（ステップＳ６０５）。Ｃ．クライアント（子）は、復号したチャットメッセージを表示する（ステップＳ６０６）。以下、同様に、Ｃ．クライアント（子）が送信するチャットメッセージは、ステップＳ３０６で作成したＤＨ共通鍵で暗号化された上で、Ｂ．クライアント（親）に送信され、Ｂ．クライアント（親）は、ステップＳ４０４で作成したＤＨ共通鍵で復号することになる。
続いて、上記Ｂ．クライアント（親）及びＣ．クライアント（子）が在室している部屋に、新たにＤ．クライアントが入室した場合の動作について説明する。図１４は、本発明の第１の実施形態の動作（Ｄ．クライアントの途中参加−１）を説明するための図である。図１４を参照すると、Ｄ．クライアント（子）が、Ｃ．クライアント（子）に対し、認証局の署名の付いたＤ．認証鍵Ｐｕｂを送信する（ステップＳ７０１）。Ｃ．クライアント（子）は、Ｄ．認証鍵Ｐｕｂを認証局の証明鍵Ｐｕｂで検証する（ステップＳ７０２）。なお、図１４の例では、Ｄ．クライアント（子）が、Ｃ．クライアント（子）に、Ｄ．認証鍵Ｐｕｂを送信しているが、Ｂ．クライアント（親）にＤ．認証鍵Ｐｕｂを送信して検証を受けることも可能である。即ち、Ａ．証明鍵Ｐｕｂと受信鍵を持っている参加中のユーザは、新規ユーザに受信鍵を配布することができる。
Ｄ．認証鍵Ｐｕｂの検証に成功すると、Ｃ．クライアント（子）は、Ｄ．クライアント（子）に対し、認証局の署名の付いたＢ．認証鍵Ｐｕｂと、Ｂの署名の付いた受信鍵Ｐｕｂと、受信鍵Ｐｒｉを送信する（ステップＳ７０３）。Ｄ．クライアント（子）は、Ｂ．認証鍵Ｐｕｂを認証局の証明鍵Ｐｕｂで検証する（ステップＳ７０４）。
Ｂ．認証鍵Ｐｕｂの検証に成功すると、Ｄ．クライアント（子）は、Ｂ．クライアント（親）の署名付きの受信鍵Ｐｕｂを、Ｂ．クライアント（親）の認証鍵Ｐｕｂで検証する（ステップＳ７０５）。受信鍵Ｐｕｂの検証に成功すると、Ｄ．クライアント（子）は、自身のＤ．送信鍵Ｐｒｉと受信鍵Ｐｕｂとを用いてＤＨ共通鍵（送信用共通鍵）を作成する（ステップＳ７０６）。このＤＨ共通鍵は、Ｄ．クライアント（子）が発言するメッセージを暗号化する際に使用される。
図１５は、図１４の続図である。図１５を参照すると、ＤＨ共通鍵（送信用共通鍵）の作成を終えたＤ．クライアント（子）は、Ｂ．クライアント（親）とＣ．クライアント（子）に対し、認証局の署名の付いたＤ．認証鍵Ｐｕｂ及び自身のＤ．認証鍵Ｐｒｉで作成した署名を付けたＤ．送信鍵Ｐｕｂを送信する（ステップＳ８０１）。Ｂ．クライアント（親）とＣ．クライアント（子）は、それぞれＤ．認証鍵Ｐｕｂを認証局の証明鍵Ｐｕｂで検証する（ステップＳ８０２）。
Ｄ．認証鍵Ｐｕｂの検証に成功すると、Ｂ．クライアント（親）とＣ．クライアント（子）は、それぞれＤ．送信鍵Ｐｕｂを、Ｄ．クライアントのＤ．認証鍵Ｐｕｂで検証する（ステップＳ８０３）。
図１６は、図１５の続図である。図１６を参照すると、Ｄ．送信鍵Ｐｕｂの検証に成功すると、Ｂ．クライアント（親）とＣ．クライアント（子）は、それぞれ受信鍵ＰｒｉとＤ．送信鍵Ｐｕｂとを用いてＤＨ共通鍵（受信用共通鍵）を作成する（ステップＳ９０１）。このＤＨ共通鍵は、Ｂ．クライアント（親）及びＣ．クライアント（子）がＤ．クライアント（子）から受信したメッセージを復号する際に使用される。
ＤＨ共通鍵（受信用共通鍵）の作成を終えたＢ．クライアント（親）は、Ｄ．クライアント（子）に対し、認証局の署名の付いたＢ．認証鍵Ｐｕｂ及び自身のＢ．認証鍵Ｐｒｉで作成した署名を付けたＢ．送信鍵Ｐｕｂを送信する（ステップＳ９０２）。同様に、Ｃ．クライアント（子）は、Ｄ．クライアント（子）に対し、認証局の署名の付いたＣ．認証鍵Ｐｕｂ及び自身のＣ．認証鍵Ｐｒｉで作成した署名を付けたＣ．送信鍵Ｐｕｂを送信する（ステップＳ９０２）。
Ｄ．クライアント（子）は、Ｂ．クライアント（親）から受信した認証鍵Ｐｕｂを認証局の証明鍵Ｐｕｂで検証する（ステップＳ９０３）。
図１７は、図１６の続図である。図１７を参照すると、Ｂ．認証鍵Ｐｕｂの検証に成功すると、Ｄ．クライアント（子）は、Ｂ．送信鍵Ｐｕｂを、Ｂ．クライアントのＢ．認証鍵Ｐｕｂで検証する（ステップＳ１００１）。Ｂ．送信鍵Ｐｕｂの検証に成功すると、Ｄ．クライアント（子）は、受信鍵Ｐｒｉと自身のＢ．送信鍵Ｐｕｂとを用いてＤＨ共通鍵（受信用共通鍵）を作成する（ステップＳ１００２）。このＤＨ共通鍵は、Ｄ．クライアント（子）がＢ．クライアント（親）から受信したメッセージを復号する際に使用される。Ｄ．クライアント（子）は、ステップＳ９０２で、Ｃ．クライアント（子）から受信したＣ．認証鍵ＰｕｂとＣ．送信鍵Ｐｕｂについても検証を行い、成功したら、受信鍵Ｐｒｉと自身のＣ．送信鍵Ｐｕｂとを用いてＤＨ共通鍵（受信用共通鍵）を作成する（ステップＳ１００１〜Ｓ１００２）。
以上により、Ｂ．クライアント（親）とＣ．クライアント（子）とＤ．クライアント（子）間でそれぞれ暗号通信に用いる共通鍵が配送された状態となる。図１８は、Ｄ．クライアント（子）が、これまでＢ．クライアント（親）とＣ．クライアント（子）間で交わされたチャットメッセージを閲覧する際の動作を表した図である。ＩＲＣプロトコルを用いた要求等に応じて、サーバ（ＩＲＣサーバ）がＤ．クライアント（子）に対して会話ログを送信したとする（ステップＳ１１０１）。Ｄ．クライアント（子）は、会話ログの時系列に沿って、Ｂ．クライアント（親）又はＣ．クライアント（子）から発信されたチャットメッセージを復号し、表示する（ステップＳ１１０２）。この時、Ｄ．クライアント（子）は、ステップＳ１００２で作成したＤＨ共通鍵（受信用共通鍵）を用いて復号することができる。
同様の原理でリアルタイムのチャットも可能となる。図１９は、本発明の第１の実施形態の動作（チャット）を説明するための図である。図１９を参照すると、Ｃ．クライアント（子）はユーザから入力されたチャットメッセージを、ステップＳ３０６で作成した送信用のＤＨ共通鍵（ＤＨ送信鍵）で暗号化し（ステップＳ１２０１）、サーバ（ＩＲＣサーバ）に暗号化したチャットメッセージを送信する（ステップＳ１２０２）。
サーバ（ＩＲＣサーバ）は、暗号化されたチャットメッセージをログに保存した上で（ステップＳ１２０３）、同じ部屋に在室しているＢ．クライアント（親）とＤ．クライアント（子）に、暗号化されたチャットメッセージを送信する（ステップＳ１２０４）。図１９に記したように、このステップＳ１２０２〜Ｓ１２０４の処理はＩＲＣプロトコルで行われる。
前記暗号化されたチャットメッセージを受信したＢ．クライアント（親）は、ステップＳ４０４で作成した受信用のＤＨ共通鍵（ＤＨ受信鍵）で、暗号化されたチャットメッセージを復号、表示する（ステップＳ１２０５、Ｓ１２０６）。同様に、Ｄ．クライアント（子）は、ステップＳ１００２で作成した受信用のＤＨ共通鍵（ＤＨ受信鍵）で、暗号化されたチャットメッセージを復号、表示する（ステップＳ１２０５、Ｓ１２０６）。
以上説明したように、本実施形態では、公開鍵暗号を用いて１対多暗号通信をする際、図２５〜図２８で示した方式のように、総当りで１対１通信を行う必要が無くなるため、利便性が向上する。また、本実施形態によれば、クライアント１組に対し、１つの共通鍵（送受信で分ける場合は２つ）で通信可能となるため、管理する鍵の数を減らすことができる。また、本実施形態によれば、上記Ｄ．クライアント（子）の途中参加時のように、途中から参加したユーザが、ログデータへアクセスすることが可能となる。
また、本実施形態では、認証局への署名付与作業の依頼の頻度を軽減することにも成功しているので、この点でも利便性が向上する。その理由は、認証局から署名を付与された鍵（認証鍵）を使用して、中間認証局の要領で、それぞれのクライアントが、自分で生成した鍵に署名をつけることで、本人性を証明できる構成を採用したことにある。
［第２の実施形態］
続いて、リアルタイムの通信ではなく、記憶媒体を媒介した情報の授受に、本発明を適用した第２の実施形態について説明する。第２の実施形態においても基本的な動作原理は、第１の実施形態と同様であるので、以下、その相違点を中心に説明する。
図２０は、本発明の第２の実施形態の暗号通信システムの構成を示す図である。図４に示した第１の実施形態との相違点は、ＩＲＣサーバの代わりに記憶媒体４０が用いられ、ディレクトリが、ＩＲＣの部屋のように、ユーザ端末５０−１〜５０−６間のデータの授受を行う場として機能する点である。なお、記憶媒体としては、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）メモリ、ＳＤカード、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、その他各種のディスクドライブなどの読み書きが容易なメモリ装置を好適に用いることができる。そして、上記第１の実施形態と同様に、あるユーザ端末（例えば、ユーザ端末５０−１）は、ＤＨ共通鍵を作成して、暗号化した上で、記憶媒体４０の所望の位置に、データを保存する。そして、他のユーザ端末のうち、ユーザ端末５０−１とＤＨ共通鍵の交換を行ったユーザ端末（例えば、ユーザ端末５０−３）は、記憶媒体４０から読み出したデータを復号することができる。一方で、ユーザ端末５０−１とＤＨ共通鍵の交換を行っていないユーザ端末（例えば、ユーザ端末５０−４）は、記憶媒体４０から読み出したデータを復号することができない。
図２１は、本実施形態の物理的なシステムの構成を示す図である。図５に示した構成との相違点は、ＩＲＣサーバ２０と情報処理装置内のＩＲＣクライアント１０−１、１０−２が、それぞれ記憶媒体４０と、情報処理装置のオペレーティングシステム（ＯＳ）５０−１、５０−２に置き換わっただけで本質的には同じである。即ち、ＯＳ５０−１、５０−２内のファイル管理部５１に加えて、ファイル管理部５１で入出力するデータの暗復号を行う暗復号処理部５２が追加されている。基本的なデータの流れは、第１の実施形態と同様に、以下の通りとなる。ある情報処理装置のユーザが、記憶媒体４０にデータを保存する操作を行うと、ファイル管理部５１は、暗復号処理部５２に当該データを送る。暗復号処理部５２は、データを暗号化し、ファイル管理部５１に返す。ファイル管理部５１は暗号化されたデータを記憶媒体４０に保存する。一方、他の情報処理装置が、記憶媒体４０に保存されている暗号化データを読み出すと、当該情報処理装置のＯＳは、暗復号処理部５２を用いて、暗号化データを復号し、ユーザに提示する。
図２２は、本実施形態のチャットシステムのソフトウェア構成を説明するための図である。本図も本質的には図６に示した第１の実施形態の構成と同じである。ＯＳ（ユーザ端末）５０−１、５０−２のファイル操作機能（上記ファイル管理部５１に相当）は、一般的なＯＳが備えているものである。図２２のＯＳ５０−１、５０−２内の暗号機能は、上記暗復号処理部５２に相当し、認証サーバ３０や他の情報処理装置との暗号鍵の授受を行い、最終的には共通鍵を作成して、データの暗復号を実施する。なお、図２１の例では、説明を簡単にするため、２台の情報処理装置を示しているが、当然に、情報処理装置の数は３以上であってもよい。
第２の実施形態において、データの保存先となる記憶媒体４０とは切り離して、鍵を管理し、別の記憶媒体を使用し、ユーザ間で交換を済ませる形態を採ることが好ましい。
その他の動作は、第１の実施形態と同様であり、各ユーザが鍵の交換を行って、一のユーザが暗号化データを記憶媒体４０に保存し、他のユーザがこれを共有した鍵で復号して利用する。このように、本実施形態によれば、コミュニティやユーザグループ毎に異なる暗号鍵を使用して、一つの記憶媒体のデータの共有を行うことが可能となる。また、第１の実施形態と同様に、これらコミュニティやユーザグループに後からユーザが増えても、すでに記憶媒体４０に暗号化されているデータを再暗号化せずに復号させることが可能となる。
上記第２の実施形態からも明らかなように、本発明は、暗号強度に関して、コンピュータの進歩や脆弱性の発見による、選定した公開鍵暗号技術の陳腐化を度外視すると、長い時間軸での暗号化／復号処理を実現できる。その理由は、Ｐｅｒｆｅｃｔ Ｆｏｒｗａｒｄ Ｓｅｃｕｒｉｔｙ要件を満たす為に鍵を短期間で更新しつつ、その頻繁に変わっていく鍵に対しての正当性を保証する機構を、運用に負荷がかからない方法で実現したことによる。なお、本発明に適用する公開鍵暗号のロジックは、ＤＨ鍵共有（離散対数を利用した狭義のＤＨ鍵共有のほか、楕円曲線暗号を用いた楕円曲線ＤＨ鍵共有（ＥＣＤＨ）等の改良方式を含む）がサポートされているものならどれでも適用可能である。
以上、本発明の各実施形態を説明したが、本発明は、上記した実施形態に限定されるものではなく、本発明の基本的技術的思想を逸脱しない範囲で、更なる変形・置換・調整を加えることができる。例えば、各図面に示したネットワーク構成、各要素の構成、メッセージの表現形態は、本発明の理解を助けるための一例であり、これらの図面に示した構成に限定されるものではない。
なお、図５、図２１に示した各装置の各部（処理手段）は、図６、図２２にて説明したように、これらの装置に搭載されたプロセッサに、そのハードウェアを用いて、上記した各処理を実行させるコンピュータプログラムにより実現することもできる。
また、上記した実施形態は、ユーザの端末として機能するコンピュータ（図２９の９０００）に、これらの端末としての機能を実現させるプログラムにより実現可能である。このようなコンピュータは、図２９のＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）９０１０、通信インタフェース９０２０、メモリ９０３０、補助記憶装置９０４０を備える構成に例示される。すなわち、図１６のＣＰＵ９０１０にて、秘密鍵配布プログラム、共通鍵作成プログラムや通信実施プログラムを実行し、その補助記憶装置９０４０等に保持された各計算パラメーターの更新処理を実施させればよい。
最後に、本発明の好ましい形態を要約する。
［第１の形態］
（上記第１の視点による暗号通信方法参照）
［第２の形態］
上記暗号通信方法において、
前記他の端末が、前記（Ａ）で準備した第１の秘密鍵と、前記（Ｂ）で共有した第２の公開鍵とを用いて、第２の共通鍵を作成するステップと、
前記一の端末が、前記（Ｂ）で共有した第２の秘密鍵と、前記（Ａ）で準備した前記一の端末の第１の公開鍵とを用いて、第２の共通鍵を作成するステップと、を含み、
前記２以上の端末がそれぞれ、前記共通鍵と、前記第２の共通鍵のいずれか一方を送信に用い、他方を受信用に用いる構成を採ることができる。
［第３の形態］
上記暗号通信方法において、さらに、
（Ｅ）第３の端末が第１の公開鍵及び第１の秘密鍵を準備するステップと、
（Ｆ）前記２以上の端末のうち一の端末が、前記（Ｂ）で共有した第２の公開鍵及び第２の秘密鍵を前記第３の端末に配布するステップと、
（Ｇ）前記第３の端末が、前記（Ｅ）で準備した第１の秘密鍵と、前記（Ｆ）で共有した第２の公開鍵とを用いて、前記２以上の端末のそれぞれとの通信に用いる共通鍵を作成するステップと、
（Ｈ）前記２以上の端末がそれぞれ、前記（Ｆ）で共有した第２の秘密鍵と、前記（Ｅ）で準備した第１の公開鍵とを用いて、前記第３の端末との通信に用いる共通鍵を作成するステップと、
を含めることができる。
［第４の形態］
上記暗号通信方法において、
前記共通鍵の作成は、ＤＨ鍵交換を用いて行われることが好ましい。
［第５の形態］
上記暗号通信方法において、
前記２以上の端末が、それぞれ所定の認証局から署名を受けた認証用公開鍵と認証用秘密鍵の組を保持し、前記認証用公開鍵を用いて、他の端末に送信する情報に署名を付与する構成を採ることができる。
［第６の形態］
（Ａ）第１の公開鍵及び第１の秘密鍵の組を準備する手段と、
（Ｂ１）第２の公開鍵及び第２の秘密鍵の組を作成し、他の端末に配布する手段と、
（Ｃ１）前記（Ａ）で準備した第１の秘密鍵と、前記（Ｂ１）で共有した第２の公開鍵とを用いて、共通鍵を作成する手段と、
（Ｄ１）前記（Ｂ１）で共有した第２の秘密鍵と、予め準備した第１の公開鍵とを用いて共通鍵を作成する他の端末と、前記（Ｃ１）で作成した共通鍵を用いて、暗号通信を実施する手段と、
を含む情報処理装置。
［第７の形態］
（Ａ）第１の公開鍵及び第１の秘密鍵の組を準備する手段と、
（Ｂ２）他の端末から第２の公開鍵及び第２の秘密鍵の組の配布を受ける手段と、
（Ｃ２）前記（Ｂ２）で共有した第２の秘密鍵と、前記（Ａ）で準備した第１の公開鍵とを用いて、共通鍵を作成する手段と、
（Ｄ２）予め準備した第１の秘密鍵と、前記（Ｂ２）で共有した第２の公開鍵とを用いて共通鍵を作成する他の端末と、前記（Ｃ２）で作成した共通鍵を用いて、暗号通信を実施する手段と、
を含む情報処理装置。
［第８の形態］
前記暗号通信は、一の情報処理装置が所定の記憶媒体に暗号データを記録し、他の情報処理装置が、前記所定の記憶媒体から暗号データを読み出して、復号する形態で行われる構成とすることができる。
［第９の形態］
（Ａ）第１の公開鍵及び第１の秘密鍵の組を準備する手段と、
（Ｂ１）第２の公開鍵及び第２の秘密鍵の組を作成し、他の端末に配布する手段と、
（Ｃ１）前記（Ａ）で準備した第１の秘密鍵と、前記（Ｂ１）で共有した第２の公開鍵とを用いて、共通鍵を作成する手段と、
（Ｄ１）前記（Ｂ１）で共有した第２の秘密鍵と、予め準備した第１の公開鍵とを用いて共通鍵を作成する他の端末と、前記（Ｃ１）で作成した共通鍵を用いて、暗号通信を実施する手段と、を含む第１の情報処理装置と、
（Ａ）第１の公開鍵及び第１の秘密鍵の組を準備する手段と、
（Ｂ２）他の端末から第２の公開鍵及び第２の秘密鍵の組の配布を受ける手段と、
（Ｃ２）前記（Ｂ２）で共有した第２の秘密鍵と、前記（Ａ）で準備した第１の公開鍵とを用いて、共通鍵を作成する手段と、
（Ｄ２）予め準備した第１の秘密鍵と、前記（Ｂ２）で共有した第２の公開鍵とを用いて共通鍵を作成する他の端末と、前記（Ｃ２）で作成した共通鍵を用いて、暗号通信を実施する手段と、を含む第２の情報処理装置と、に接続され、
前記第１、第２の情報処理装置が本人性を証明するために使用する署名に認証を与える認証局装置。
［第１０の形態］
（Ａ）第１の公開鍵及び第１の秘密鍵の組を準備する処理と、
（Ｂ１）第２の公開鍵及び第２の秘密鍵の組を作成し、他の端末に配布する処理と、
（Ｃ１）前記（Ａ）で準備した第１の秘密鍵と、前記（Ｂ１）で共有した第２の公開鍵とを用いて、共通鍵を作成する処理と、
（Ｄ１）前記（Ｂ１）で共有した第２の秘密鍵と、予め準備した第１の公開鍵とを用いて共通鍵を作成する他の端末と、前記（Ｃ１）で作成した共通鍵を用いて、暗号通信を実施する処理と、
を情報処理装置に実行させるプログラム。
［第１１の形態］
（Ａ）第１の公開鍵及び第１の秘密鍵の組を準備する処理と、
（Ｂ２）他の端末から第２の公開鍵及び第２の秘密鍵の組の配布を受ける処理と、
（Ｃ２）前記（Ｂ２）で共有した第２の秘密鍵と、前記（Ａ）で準備した第１の公開鍵とを用いて、共通鍵を作成する処理と、
（Ｄ２）予め準備した第１の秘密鍵と、前記（Ｂ２）で共有した第２の公開鍵とを用いて共通鍵を作成する他の端末と、前記（Ｃ２）で作成した共通鍵を用いて、暗号通信を実施する処理と、
を情報処理装置に実行させるプログラム。
なお、上記第６〜第１１の形態は、第１の形態と同様に、第２〜第５の形態に展開することが可能である。
なお、上記の特許文献の各開示を、本書に引用をもって繰り込むものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の開示の枠内において種々の開示要素（各請求項の各要素、各実施形態ないし実施例の各要素、各図面の各要素等を含む）の多様な組み合わせ、ないし選択（部分的削除を含む）が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。特に、本書に記載した数値範囲については、当該範囲内に含まれる任意の数値ないし小範囲が、別段の記載のない場合でも具体的に記載されているものと解釈されるべきである。
本発明は、以下の分野や応用製品に好適に適用可能であるが、勿論、これらの分野や応用製品に限定されるものではない。
・（オフライン）可搬記憶媒体のデータ保護／データシェアリング
・ＵＳＢ、ＳＤ、ＳＳＤメモリ製品等
・（オンライン）クラウドのデータ保護／データシェアリング
・ｗｅｂコンテンツ
・データサーバ
・ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）
・Ｂｉｇ Ｄａｔａ
・ＳＮＳ（Ｓｏｃｉａｌ Ｎｅｔｗｏｒｋｉｎｇ Ｓｅｒｖｉｃｅ）構築
・在宅勤務システム等
・時間軸を超えた相互認証
・（［現在］−−−［過去］の応用）家系図情報や歴代の親族の記録など
（他界していて、実際には相互認証できない人との相互認証を実現）
・（［現在］−−−［未来］の応用）宇宙開発
（自分は死んでしまうが、数十光年先に存在する相手との相互認証を実現）
・リアルタイム通信の保護
・テキストチャット通信サービス
・ＰＰ２Ｐ型ＳＮＳ通信サービス
・サーバ・クライアント型通信サービス
・ボイスチャット通信サービス
・Ｐ２Ｐ型音声通信サービス
・電子会議通信サービス
１０、１０−１〜１０−６ ＩＲＣクライアント
１１ ＩＲＣ処理部
１２、５２ 暗復号処理部
２０、２０−Ａ〜２０−Ｄ ＩＲＣサーバ
３０ 認証サーバ
４０ 記憶媒体
５０−１〜５０−６ ＯＳ
５１ ファイル管理部
１００−１、１００−２ 情報処理装置（端末）

Claims (10)

  1. （Ａ）２以上の端末がそれぞれ第１の公開鍵と第１の秘密鍵の組を準備するステップと、
    （Ｂ）前記２以上の端末のうち一の端末が第２の公開鍵と第２の秘密鍵の組を作成し、事前に取り決めた鍵の配送手段を用いて、他の端末に配布するステップと、
    （Ｃ）前記２以上の端末のうち一の端末が、前記（Ａ）で準備した第１の秘密鍵と、前記（Ｂ）で共有した第２の公開鍵とを用いて、共通鍵を作成するステップと、
    （Ｄ）前記２以上の端末のうち他の端末が、前記（Ｂ）で共有した第２の秘密鍵と、前記（Ａ）で準備した前記一の端末の第１の公開鍵とを用いて、前記一の端末との通信に用いる共通鍵を作成するステップと、
    （Ｅ）前記端末の組が、前記共通鍵を用いて、暗号通信を実施するステップと、
    を含む暗号通信方法。
  2. 前記他の端末が、前記（Ａ）で準備した第１の秘密鍵と、前記（Ｂ）で共有した第２の公開鍵とを用いて、第２の共通鍵を作成するステップと、
    前記一の端末が、前記（Ｂ）で共有した第２の秘密鍵と、前記（Ａ）で準備した前記他の端末の第１の公開鍵とを用いて、第２の共通鍵を作成するステップと、を含み、
    前記２以上の端末がそれぞれ、前記共通鍵と、前記第２の共通鍵のいずれか一方を送信に用い、他方を受信用に用いる請求項１の暗号通信方法。
  3. （Ｆ）第３の端末が第１の公開鍵及び第１の秘密鍵を準備するステップと、
    （Ｇ）前記２以上の端末のうち一の端末が、前記（Ｂ）で共有した第２の公開鍵及び第２の秘密鍵を前記第３の端末に配布するステップと、
    （Ｈ）前記第３の端末が、前記（Ｆ）で準備した第１の秘密鍵と、前記（Ｇ）で共有した第２の公開鍵とを用いて、前記２以上の端末のそれぞれとの通信に用いる共通鍵を作成するステップと、
    （Ｉ）前記２以上の端末がそれぞれ、前記（Ｂ）で共有した第２の秘密鍵と、前記（Ｆ）で準備した第１の公開鍵とを用いて、前記第３の端末との通信に用いる共通鍵を作成するステップと、
    を含む請求項２の暗号通信方法。
  4. 前記共通鍵の作成が、ＤＨ鍵交換を用いて行われる請求項１から３いずれか一の暗号通信方法。
  5. 前記２以上の端末が、それぞれ所定の認証局から署名を受けた認証用公開鍵と認証用秘密鍵の組を保持し、前記認証用公開鍵を用いて、他の端末に送信する情報に署名を付与する請求項１から４いずれか一の暗号通信方法。
  6. （Ａ）第１の公開鍵及び第１の秘密鍵の組を準備する手段と、
    （Ｂ１）第２の公開鍵及び第２の秘密鍵の組を作成し、事前に取り決めた鍵の配送手段を用いて、他の端末に配布する手段と、
    （Ｃ１）前記（Ａ）で準備した第１の秘密鍵と、前記（Ｂ１）で共有した第２の公開鍵とを用いて、共通鍵を作成する手段と、
    （Ｄ１）前記（Ｂ１）で共有した第２の秘密鍵と、予め準備した第１の公開鍵とを用いて共通鍵を作成する他の端末と、前記（Ｃ１）で作成した共通鍵を用いて、暗号通信を実施する手段と、
    を含む情報処理装置。
  7. （Ａ）第１の公開鍵及び第１の秘密鍵の組を準備する手段と、
    （Ｂ２）事前に取り決めた鍵の配送手段を用いて、他の端末から第２の公開鍵及び第２の秘密鍵の組の配布を受ける手段と、
    （Ｃ２）前記（Ｂ２）で共有した第２の秘密鍵と、前記（Ａ）で準備した第１の公開鍵とを用いて、共通鍵を作成する手段と、
    （Ｄ２）予め準備した第１の秘密鍵と、前記（Ｂ２）で共有した第２の公開鍵とを用いて共通鍵を作成する他の端末と、前記（Ｃ２）で作成した共通鍵を用いて、暗号通信を実施する手段と、
    を含む情報処理装置。
  8. 前記暗号通信は、一の情報処理装置が所定の記憶媒体に暗号データを記録し、他の情報処理装置が、前記所定の記憶媒体から暗号データを読み出して、復号する形態で行われる請求項６又は７の情報処理装置。
  9. （Ａ）第１の公開鍵及び第１の秘密鍵の組を準備する処理と、
    （Ｂ１）第２の公開鍵及び第２の秘密鍵の組を作成し、事前に取り決めた鍵の配送手段を用いて、他の端末に配布する処理と、
    （Ｃ１）前記（Ａ）で準備した第１の秘密鍵と、前記（Ｂ１）で共有した第２の公開鍵とを用いて、共通鍵を作成する処理と、
    （Ｄ１）前記（Ｂ１）で共有した第２の秘密鍵と、予め準備した第１の公開鍵とを用いて共通鍵を作成する他の端末と、前記（Ｃ１）で作成した共通鍵を用いて、暗号通信を実施する処理と、
    を情報処理装置に実行させるプログラム。
  10. （Ａ）第１の公開鍵及び第１の秘密鍵の組を準備する処理と、
    （Ｂ２）事前に取り決めた鍵の配送手段を用いて、他の端末から第２の公開鍵及び第２の秘密鍵の組の配布を受ける処理と、
    （Ｃ２）前記（Ｂ２）で共有した第２の秘密鍵と、前記（Ａ）で準備した第１の公開鍵とを用いて、共通鍵を作成する処理と、
    （Ｄ２）予め準備した第１の秘密鍵と、前記（Ｂ２）で共有した第２の公開鍵とを用いて共通鍵を作成する他の端末と、前記（Ｃ２）で作成した共通鍵を用いて、暗号通信を実施する処理と、
    を情報処理装置に実行させるプログラム。
JP2019520297A 2017-05-25 2018-05-23 暗号通信方法、情報処理装置及びプログラム Active JP6801921B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2017103619 2017-05-25
JP2017103619 2017-05-25
PCT/JP2018/019903 WO2018216749A1 (ja) 2017-05-25 2018-05-23 暗号通信方法、情報処理装置及びプログラム

Publications (2)

Publication Number Publication Date
JPWO2018216749A1 JPWO2018216749A1 (ja) 2020-03-26
JP6801921B2 true JP6801921B2 (ja) 2020-12-16

Family

ID=64396508

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2019520297A Active JP6801921B2 (ja) 2017-05-25 2018-05-23 暗号通信方法、情報処理装置及びプログラム

Country Status (3)

Country Link
US (1) US11411744B2 (ja)
JP (1) JP6801921B2 (ja)
WO (1) WO2018216749A1 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3084554B1 (fr) * 2018-07-30 2022-02-18 Ingenico Group Procede de transmission securisee de donnees entre un terminal de paiement et une imprimante sans fil
CN114765595B (zh) * 2021-01-04 2024-04-26 腾讯科技（深圳）有限公司 聊天消息的显示方法、发送方法、装置、电子设备及介质

Family Cites Families (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS57141155A (en) * 1981-02-26 1982-09-01 Nec Corp Method and device for secret communication
JPS6354037A (ja) * 1986-08-22 1988-03-08 Nec Corp キ−配送装置
JPH0766803A (ja) 1993-08-23 1995-03-10 Hitachi Ltd 同報暗号通信方法およびシステム
US5761305A (en) * 1995-04-21 1998-06-02 Certicom Corporation Key agreement and transport protocol with implicit signatures
DE19847941A1 (de) 1998-10-09 2000-04-13 Deutsche Telekom Ag Verfahren zum Etablieren eines gemeinsamen krytografischen Schlüssels für n Teilnehmer
US6636968B1 (en) 1999-03-25 2003-10-21 Koninklijke Philips Electronics N.V. Multi-node encryption and key delivery
JP2001057551A (ja) * 1999-08-18 2001-02-27 Nec Corp 暗号化通信システムおよび暗号化通信方法
JP2002041461A (ja) 2000-07-31 2002-02-08 Nippon Telegraph & Telephone East Corp 電子会議システムにおける会議資料の共用方法ならびにシステム
JP3805610B2 (ja) 2000-09-28 2006-08-02 株式会社日立製作所 閉域グループ通信方法および通信端末装置
JP4371629B2 (ja) * 2002-04-25 2009-11-25 日本電気株式会社 グループ暗号通信方法、認証方法、計算機及びプログラム
US7778422B2 (en) * 2004-02-27 2010-08-17 Microsoft Corporation Security associations for devices
JP2005039868A (ja) 2004-11-05 2005-02-10 Fujitsu Ltd 鍵管理サーバ、チャットシステムの端末装置、チャットシステム及び記録媒体
CN1773905B (zh) * 2004-11-10 2010-08-18 日电（中国）有限公司 在安全通信系统中生成匿名公钥的方法、设备和系统
JP2007060213A (ja) 2005-08-24 2007-03-08 Fuji Xerox Co Ltd 鍵配布装置及び鍵配布方法
GB2436668B (en) * 2006-03-28 2011-03-16 Identum Ltd Electronic data communication system
JP2007288694A (ja) * 2006-04-19 2007-11-01 Nec Corp 秘匿通信システムおよびチャネル制御方法
US8270613B2 (en) * 2006-05-29 2012-09-18 Nec Corporation System for disabling unauthorized person, encryption device, encryption method, and program
KR101424971B1 (ko) * 2007-04-06 2014-08-13 삼성전자주식회사 Ｕｍｓ 기기의 컨텐츠를 시간 정보를 이용하여 보호하는방법 및 이를 위한 장치
JP5257357B2 (ja) * 2007-05-25 2013-08-07 日本電気株式会社 鍵生成装置、暗号化装置及び復号装置
EP2154667A4 (en) * 2007-05-25 2015-11-11 Nec Corp KEY EXCHANGE DEVICE AND KEY EXCHANGE METHOD
JP5288087B2 (ja) * 2007-06-11 2013-09-11 日本電気株式会社 秘匿通信ネットワークにおける暗号鍵管理方法および装置
JP5273047B2 (ja) * 2007-08-09 2013-08-28 日本電気株式会社 鍵交換装置
JP5012574B2 (ja) * 2008-03-03 2012-08-29 日本電気株式会社 共通鍵自動共有システム及び共通鍵自動共有方法
JP2010204466A (ja) * 2009-03-04 2010-09-16 Toshiba Corp 暗号装置、復号装置、鍵生成装置及びプログラム
US8874991B2 (en) * 2011-04-01 2014-10-28 Cleversafe, Inc. Appending data to existing data stored in a dispersed storage network
WO2013009420A1 (en) * 2011-06-09 2013-01-17 Power Tagging Technologies, Inc. System and method for grid based cyber security
US9049011B1 (en) * 2012-08-15 2015-06-02 Washington State University Secure key storage and distribution
US10103885B2 (en) * 2016-01-20 2018-10-16 Mastercard International Incorporated Method and system for distributed cryptographic key provisioning and storage via elliptic curve cryptography
US10397206B2 (en) * 2016-01-26 2019-08-27 Red Hat, Inc. Symmetric encryption key generation/distribution
US10826875B1 (en) * 2016-07-22 2020-11-03 Servicenow, Inc. System and method for securely communicating requests

Also Published As

Publication number Publication date
WO2018216749A1 (ja) 2018-11-29
JPWO2018216749A1 (ja) 2020-03-26
US11411744B2 (en) 2022-08-09
US20200169418A1 (en) 2020-05-28

Similar Documents

Publication Publication Date Title
US11575660B2 (en) End-to-end encryption for personal communication nodes
KR101977109B1 (ko) 해시함수 기반의 대규모 동시 전자서명 서비스 시스템 및 그 방법
US10541814B2 (en) End-to-end encryption during a secure communication session
US20150281185A1 (en) Cloud Collaboration System With External Cryptographic Key Management
US10396987B2 (en) Securely provisioning an application with user information
US20170033925A1 (en) Methods and apparatus for implementing a communications system secured using one-time pads
CN106790037B (zh) 一种用户态加密的即时通讯方法与系统
WO2022199186A1 (zh) 一种基于量子技术的物联网通信系统
CN111193703B (zh) 在分散式网络中使用的通信装置和通信方法
TW201724802A (zh) 用於傳送和接收訊息的使用者終端和方法和儲存電腦程式的電腦可讀記錄介質
US20170142578A1 (en) System and method for providing secure and anonymous device-to-device communication
US20180083947A1 (en) Stateless Server-Based Encryption Associated With A Distribution List
JP6801921B2 (ja) 暗号通信方法、情報処理装置及びプログラム
US20090216837A1 (en) Secure reservationless conferencing
JP2019102970A (ja) データ共有サーバ装置、鍵生成サーバ装置、通信端末、プログラム
US11575658B2 (en) Encryption device, a communication system and method of exchanging encrypted data in a communication network
JP2007060213A (ja) 鍵配布装置及び鍵配布方法
JP2003345742A (ja) ＣＵＧ（ＣｌｏｓｅｄＵｓｅｒＧｒｏｕｐ）管理方法及びＣＵＧ提供システム及びＣＵＧ提供プログラム及びＣＵＧ提供プログラムを格納した記憶媒体
KR102269753B1 (ko) 컨소시엄 블록체인 네트워크에서의 프라이빗 키를 백업 및 복원하는 방법 및 장치
KR102191111B1 (ko) 블록 체인을 이용하여 익명 메시지 서비스를 제공하기 시스템 및 방법
US20200045026A1 (en) Centralized Data Management and SaaS with End-to-End Encryption
JP4781896B2 (ja) 暗号化メッセージ送受信方法、送信者装置、受信者装置、鍵サーバ、および暗号化メッセージ送受信システム
Shin et al. An effective authentication mechanism for ubiquitous collaboration in heterogeneous computing environment
CN113535852A (zh) 基于区块链的文件处理方法、文件访问方法、装置及系统
CN114186213A (zh) 基于联邦学习的数据传输方法及装置、设备和介质

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20191122

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20200526

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200701

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20200811

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200907

C60 Trial request (containing other claim documents, opposition documents)

Free format text: JAPANESE INTERMEDIATE CODE: C60

Effective date: 20200907

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20200915

C21 Notice of transfer of a case for reconsideration by examiners before appeal proceedings

Free format text: JAPANESE INTERMEDIATE CODE: C21

Effective date: 20200929

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: 20201027

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20201119

R150 Certificate of patent or registration of utility model

Ref document number: 6801921

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150