JP4770157B2

JP4770157B2 - 情報通信システム

Info

Publication number: JP4770157B2
Application number: JP2004334588A
Authority: JP
Inventors: 勉坂上
Original assignee: Mitsubishi Electric Corp
Current assignee: Mitsubishi Electric Corp
Priority date: 2004-11-18
Filing date: 2004-11-18
Publication date: 2011-09-14
Anticipated expiration: 2024-11-18
Also published as: JP2006148454A

Description

この発明は、公開鍵証明書のデータベースをもつ信頼点証明書管理サーバ並びに該サーバを利用する情報端末及びそれらを含む情報通信システムに関する。

データの暗号化の方式として公開鍵暗号方式と共通鍵暗号方式がよく知られている。共通鍵暗号方式は通信を行う送信者と受信者の間で共通の鍵を保持し、送信者は共通鍵で暗号化した情報を送信し、受信者は共通鍵を用いてこれを解読する。共通鍵暗号方式を用いた通信はその前提として、共通鍵を秘密裏に共有する必要がある。共通鍵暗号方式は、鍵を送信者から受信者へどのように安全に渡すかという問題、受信者の数だけ鍵が必要であるという問題がある。

一方、公開鍵暗号方式は暗号化と復号化に異なった鍵を使い、一方を公開鍵、もう一方を秘密鍵にするものである。このとき、公開鍵と秘密鍵は１つずつが対応するペアになっていて、ある公開鍵で暗号化するとペアの秘密鍵でしか復号できない。また、秘密鍵で暗号化されるとペアの公開鍵でしか復号することができないといった特徴がある。

一般に信頼できない通信路を使用してメッセージの送受信を行う場合、送信者はメッセージを送信者自身が作成・送信したことや、途中で改ざんが行われていないことを受信者に示すために、電子署名をメッセージに添付することができる。電子署名はメッセージの送信者が、送信したメッセージに対してハッシュ関数と呼ばれる技術を用いて所定長の電子データ（ハッシュ値）を生成し、そのハッシュ値を送信者の持つ秘密鍵を用いて暗号化することによって作成される。

メッセージの受信者は、電子署名が添付されたメッセージを受信した場合、そのメッセージが確かに送信者によって作成され、かつ改ざんされていないことを確認するために、メッセージに添付された電子署名を検証する必要がある。

検証方法としては、電子署名を送信者の公開鍵を用いて復号し、送信者が作成したハッシュ値を得、元のメッセージのハッシュ値を計算し、復号したハッシュ値との比較を行う。両者が一致した場合、メッセージは確かに送信者が作成・送信したもので、かつ改ざんされていないことが保障され、一致しない場合には、送信者と電子署名の作成者が異なっているか、通信路上でメッセージの改ざんが行われたことを示している。

上記の検証動作をする際には、送信者の公開鍵が必要であるが、公開鍵自身にはその公開鍵の所有者や安全性に関する情報は含まれない。したがって通常電子署名は、信頼のおける第三者機関（認証局）が、公開鍵の所有者やその公開鍵の有効性を保証した公開鍵証明書が添付された形で使用される。公開鍵証明書は、公開鍵所有者の情報、公開鍵データ、証明書の有効期限、証明書を発行した認証局情報などのデータを組み合わせたものに対して信頼のおける第三者機関である認証局が電子署名を行い、発行したものである。この公開鍵証明書により、その公開鍵の所有者が確かに記載された所有者であることを認証局が保証する。

したがって、メッセージの受信者は送信者の電子署名を検証するには公開鍵証明書の検証を行う必要がある。公開鍵証明書の検証は、検証対象の証明書に添付された認証局署名の検証、有効期限の検証、証明書が失効していないことの検証、公開鍵証明書を発行した認証局の証明書が失効していないことの検証が必要であり、これら全てに問題がない場合、その公開鍵証明書は有効であることが確認できる。

また、複数の認証局を経由して発行された公開鍵証明書が検証対象である場合、検証対象の公開鍵証明書から、受信者が信頼する認証局の公開鍵証明書までを順にたどり、受信者が信頼する認証局の公開鍵証明書までの全ての公開鍵証明書を検証し、有効であることが確認できれば、その公開鍵証明書が有効であることが確認できる。この場合、最上位の認証局が発行した公開鍵証明書があれば、それより下位の認証局が発行した公開鍵証明書を検証することが可能である。

したがって、従来の公開鍵暗号を用いた通信においては、情報端末（検証者）は自身の信頼する認証局（信頼点）全ての公開鍵証明書を、あらかじめ情報端末の記憶領域等に保管しておく必要がある。なお、記憶容量の少ない情報端末の公開鍵証明書をサーバで集中管理する方法も提案されているが、信頼点の公開鍵証明書を管理する方法及び公開鍵証明書の検証をどこで行うかという点については開示されていない（例えば特許文献１参照）。

特開平１１−３１７７３５（図３）

従来の公開鍵暗号を使用した通信では、信頼点全ての公開鍵証明書を情報端末（検証者）の記憶領域等に保管する構成になっているので、信頼点の有効期限が切れたり、信頼点の公開鍵証明書が更新されたりした場合には、情報端末が個々に自己の記憶領域内の信頼点を更新したり、追加したりする必要があった。

また一般に、インターネット等のオープンな環境で使用される公開鍵基盤では、商用の証明書発行局を信頼点とするために、信頼点が多数存在している。そのため、検証者が携帯電話やＰＤＡ等の記憶領域に制限があるような機器である場合には、多数の信頼点の公開鍵証明書全てを検証者の記憶領域に保管しておくのが困難であり、必要な信頼点を使用できないといった問題もあった。

本発明は、上述の問題を解決するためになされたもので、情報端末（検証者）が個々に信頼点の更新や追加を行う必要がなく、必要な信頼点を全て使用することのできる信頼点証明書管理サーバを得るものである。

この発明に係る情報通信システムは、情報端末と、情報端末との暗号通信に用いられる第１の公開鍵を生成するサイトと、第１の公開鍵を証明する第１の公開鍵証明書に第１の公開鍵を含め自身の第１の電子署名を添付して発行し、第１の公開鍵とは異なる自身の鍵である第２の公開鍵を生成し第２の公開鍵を証明する第２の公開鍵証明書に自身の第２の電子署名を添付して発行するサイトと異なる認証局と、認証局により発行された第２の公開鍵証明書を保存し管理する信頼点証明書管理サーバと、を備えた情報通信システムであって、信頼点証明書管理サーバは、認証局により発行された第２の公開鍵証明書を保存するデータベースと、情報端末から第２の公開鍵証明書の送付要求を受付ける受付手段と、送付要求に応じてデータベース内を検索し、要求された第２の公開鍵証明書を発見すると第２の公開鍵証明書を情報端末に送付する結果通知手段と、備え、情報端末は、サイトへの送付要求に応じてサイトから送付された第１の公開鍵証明書を受付ける第１の受付手段と、信頼点証明書管理サーバへの送付要求に応じて信頼点証明書管理サーバから送付された第２の公開鍵証明書を受付ける第２の受付手段と、第２の公開鍵証明書に含まれる第２の公開鍵を用いて第１の公開鍵証明書に添付された認証局の第１の電子署名を検証し、第１の電子署名の検証ができた場合に第１の公開鍵証明書は認証局により発行されたものであるとする検証手段と、を備え、第１の公開鍵証明書は認証局により発行されたものであると検証手段が確認した場合に、情報端末は、第１の公開鍵証明書に含まれる第１の公開鍵を用いてサイトとの暗号通信を開始するものである。

この発明によれば、情報通信システムは、情報端末と、情報端末との暗号通信に用いられる第１の公開鍵を生成するサイトと、第１の公開鍵を証明する第１の公開鍵証明書に第１の公開鍵を含め自身の第１の電子署名を添付して発行し、第１の公開鍵とは異なる自身の鍵である第２の公開鍵を生成し第２の公開鍵を証明する第２の公開鍵証明書に自身の第２の電子署名を添付して発行するサイトと異なる認証局と、認証局により発行された第２の公開鍵証明書を保存し管理する信頼点証明書管理サーバと、を備えた情報通信システムであって、信頼点証明書管理サーバは、認証局により発行された第２の公開鍵証明書を保存するデータベースと、情報端末から第２の公開鍵証明書の送付要求を受付ける受付手段と、送付要求に応じてデータベース内を検索し、要求された第２の公開鍵証明書を発見すると第２の公開鍵証明書を情報端末に送付する結果通知手段と、を備え、情報端末は、サイトへの送付要求に応じてサイトから送付された第１の公開鍵証明書を受付ける第１の受付手段と、信頼点証明書管理サーバへの送付要求に応じて信頼点証明書管理サーバから送付された第２の公開鍵証明書を受付ける第２の受付手段と、第２の公開鍵証明書に含まれる第２の公開鍵を用いて第１の公開鍵証明書に添付された認証局の第１の電子署名を検証し、第１の電子署名の検証ができた場合に第１の公開鍵証明書は認証局により発行されたものであるとする検証手段と、を備え、第１の公開鍵証明書は認証局により発行されたものであると検証手段が確認した場合に、情報端末は、第１の公開鍵証明書に含まれる第１の公開鍵を用いてサイトとの暗号通信を開始することにより、サイト以外のものがサイトになりすまして第１の公開鍵証明書を送付した場合であっても、情報端末が信頼点証明書管理サーバから取得した第２の公開鍵証明書を用いて第１の公開鍵証明書に添付された第１の電子署名を検証するため、なりすましによる不正を見破ることができる。

実施の形態１．
図１は、実施の形態１におけるシステム概念図であって、１００は信頼点の公開鍵証明書を検証者に提供する信頼点証明書管理サーバ、２００は検証者が使用する携帯電話やＰＤＡ等の情報端末、３００は信頼点証明書管理サーバ１００の公開鍵証明書を発行する第１の認証局、４００はインターネット上の一般のサイト、５００はサイト４００の公開鍵証明書を発行する第２の認証局、Ａはインターネットなどのオープンなネットワークであるデータ通信経路である。

図２は信頼点証明書管理サーバ１００の構成を示すものであって、１０１は信頼点証明書管理サーバ１００自身の公開鍵と秘密鍵のペアを生成する自己鍵ペア生成手段、１０２は認証局３００に対して、当該公開鍵の公開鍵証明書の発行を申請する自己証明書申請手段、１０３は当該秘密鍵と当該公開鍵証明書を保管しておくための自己証明書保管手段、１０４は情報端末２００から公開鍵証明書の送付要求を受取る受付手段、１０５は信頼点の公開鍵証明書を保存しておくためのデータベース、１０６はデータベース１０５に信頼点の公開鍵証明書を保存したり、不要になった公開鍵証明書を削除したりするデータベース管理手段、１０７は受付手段１０４に対して要求された公開鍵証明書をデータベース１０５内に検索し、検索結果を情報端末２００に通知する結果通知手段、１０８は結果通知手段１０７が公開鍵証明書を発見できなかった場合にその公開鍵証明書よりも上位の公開鍵証明書を入手する上位公開鍵証明書入手手段である。

図３は情報端末２００の構成を示すものであって、２０１は信頼点証明書管理サーバ１００やサイト４００などに公開鍵証明書を要求する証明書要求手段、２０２は公開鍵証明書の検証を行う証明書検証手段、２０３は認証局３００の公開鍵証明書を保管しておく証明書保管手段、２０４は送付された公開鍵証明書を受取る証明書受取り手段である。

次にこのように構成されたシステムについて、情報端末２００がインターネット上の一般サイトと通信を行う前の準備段階について図４を用いて説明する。図４はインターネット上の一般サイトと通信を開始する前の準備段階の動作を示すシーケンス図である。まず、信頼点証明書管理サーバ１００は自己鍵ペア生成手段１０１を用いて信頼点証明書管理サーバ１００自身の秘密鍵と公開鍵のペアを生成する（ＳＴ００１）。次に自己証明書申請手段１０２を用いて認証局３００に対して当該公開鍵の公開鍵証明書の発行申請をおこなう（ＳＴ００２）。この発行申請を受付けた認証局３００はこの公開鍵に対する公開鍵証明書を発行し、信頼点証明書管理サーバ１００に送付し、信頼点証明書管理サーバ１００は、この送付された公開鍵証明書と秘密鍵を自己証明書保管手段で保管する（ＳＴ００３）。一方、情報端末２００は認証局３００を自己の信頼点とするためには、認証局３００の公開鍵証明書を、証明書保管手段２０３を用いて、自身のメモリ内に保管する（ＳＴ００４）。

次に、認証局５００の公開鍵証明書を信頼点証明書管理サーバに保管することによって、情報端末２００の使用者が認証局５００を信頼点としている場合について説明する。この場合、信頼点証明書管理サーバ１００内の管理手段１０６を用いて認証局５００から送付される認証局５００の公開鍵証明書をデータベース１０５に保存する（ＳＴ００５）。一方、サイト４００は自身が通信に使用する公開鍵と秘密鍵のペアを生成する（ＳＴ００６）。その後、サイト４００はこの公開鍵の公開鍵証明書の発行申請を認証局５００に対しておこなう（ＳＴ００７）。この発行申請を受付けた認証局５００はこの公開鍵に対する公開鍵証明書を発行し、サイト４００に送付し、これを受取ったサイト４００は、この公開鍵証明書と秘密鍵を保管しておく（ＳＴ００８）。

以上のようにＳＴ００１〜ＳＴ００８までを行うことにより、情報端末２００は任意の公開鍵証明書を、認証局５００が発行した公開鍵証明書か否か、検証することが可能となる。また、信頼点証明書管理サーバ１００は情報端末２００から認証局５００の公開鍵証明書を要求されたときには、その要求に応じ情報端末２００に送付することが可能となる。また、信頼点が発行した公開鍵証明書のデータベース１０５を信頼点証明書管理サーバ１００内に設置することにより、情報端末２００のユーザが必要なだけの公開鍵証明書を保存することが可能となる。一般に、１つの公開鍵証明書の容量は１キロバイト程度なので、ほぼ無制限に信頼点を設定することが可能である。

次に図５を用いて、情報端末２００がサイト４００と公開鍵基盤を利用した通信をおこなう際の動作について説明する。図５は情報端末２００がサイト４００と公開鍵基盤による通信を行う際の動作を示すシーケンス図である。まず、サイト４００と通信を行おうとする情報端末２００の使用者は、サイト４００に対して、証明書要求手段２０１を用いてサイト４００の公開鍵とその公開鍵証明書の送付を要求する（ＳＴ１０１）。この要求を受取ったサイト４００は情報端末２００に認証局５００が発行したサイト４００の公開鍵証明書を送付する（ＳＴ１０２）。証明書受取り手段２０４でこれらの送付を受けた情報端末２００は、この公開鍵証明書を検証するために、信頼点証明書管理サーバ１００と接続し、認証局５００の公開鍵証明書を得る必要があるので、証明書要求手段２０１を用いて、信頼点証明書管理サーバ１００の公開鍵証明書を要求する（ＳＴ１０３）。この要求を受けて、信頼点証明書管理サーバ１００は情報端末２００に自己の公開鍵証明書を送付し、情報端末２００は証明書受取り手段２０４によってそれを受取る（ＳＴ１０４）。

ここで、情報端末２００は認証局証明書保管手段２０３において保管しておいた認証局３００の公開鍵証明書を使用して、ＳＴ１０４で送付された公開鍵証明書の検証を、サーバ証明書検証手段２０２においておこなう（ＳＴ１０５）。ＳＴ１０５において信頼点証明書管理サーバ１００の公開鍵証明書の検証を行うことにより、他人による信頼点証明書管理サーバ１００へのなりすましがあった場合においては、これを発見することができる。ＳＴ１０５の検証において、送付された公開鍵証明書が、認証局３００が発行したものと確認されると、情報端末２００は証明書要求手段２０１を用いて、信頼点証明書管理サーバ１００に、サイト４００の公開鍵証明書の発行者名と発行者の鍵識別子等を送付することにより、サイト４００に公開鍵証明書を発行した認証局５００の公開鍵証明書を要求する（ＳＴ１０６）。

次に受付手段１０４でＳＴ１０６における要求を受付けた信頼点証明書管理サーバ１００は、結果通知手段１０７を用いてデータベース１０５内を検索し、その結果、認証局５００の公開鍵証明書を発見すると、その公開鍵証明書を情報端末２００に送付し、情報端末２００は証明書受取り手段２０４を用いてそれを受取る（ＳＴ１０７）。この、公開鍵証明書を受取ると、情報端末２００は、証明書検証手段２０２を用いて、ＳＴ１０２でサイト４００から受取った公開鍵証明書の検証をおこなう（ＳＴ１０８）。検証の結果、サイト４００から受取った公開鍵証明書が認証局５００から発行されたものと確認されると、ＳＴ１０２で送付された公開鍵証明書をサイト４００のものとみなして、その公開鍵を用いて発注情報などの送信が可能となる（ＳＴ１０９）。

以上のようにＳＴ１０１〜ＳＴ１０９を行うことにより、情報端末２００はサイト４００と公開鍵基盤を用いた通信を行うことが可能となる。また、ＳＴ１０２においてサイト４００以外のものが、サイト４００になりすましてその公開鍵証明書を送付した場合であっても、ＳＴ１０８における公開鍵証明書の検証により、なりすましによる不正を見破ることが可能である。

また、認証局５００を信頼点としない場合、すなわち図４におけるＳＴ００５の認証局５００からの公開鍵証明書の送付がない場合においては、図５のＳＴ１０７においてデータベース１０５内の検索を行っても、当該公開鍵証明書は発見されない。このときは、結果通知手段１０７は情報端末２００に対して公開鍵証明書を発見できなかった旨を通知する。

また、上記の例では、ＳＴ１０２において、情報端末２００はサイト４００から公開鍵証明書を受取っているが、この公開鍵証明書はディレクトリサーバなどの公開鍵証明書の提供サービスを行っている機関等から得ても良い。

さらに、信頼点の公開鍵証明書のデータベース１０５を信頼点証明書管理サーバ１００に設置することにより、信頼点の公開鍵証明書の有効期限が切れていたり、更新されていたりした場合であっても、情報端末２００のユーザは自ら逐次更新する必要はなく、信頼点証明書管理サーバ１００において、信頼点の公開鍵証明書を一括管理することが可能である。このとき、有効期限の切れた公開鍵証明書は削除するような構成にしても良いが、そのままデータベース１０５に保存しておくような構成にしても良い。そのまま保存しておく構成にすれば、ＳＴ１０６において情報端末２００が信頼点証明書管理サーバ１００に対して公開鍵証明書を要求する際に、日時を指定する情報が含まれている場合は、その指定日時において有効な公開鍵証明書を検索することが可能である。

さらに、一般的に大きな処理能力が必要である公開鍵証明書の検証を、信頼点証明書管理サーバ１００ではなく情報端末２００が行う構成になっているので、信頼点証明書管理サーバ１００が複数の情報端末のサーバになっているような場合であっても、公開鍵証明書の検証は個々の情報端末が行うので、公開鍵証明書の検証作業の集中による処理能力低下を防ぐことが可能である。

実施の形態２．
実施の形態１においては、サイト４００側の認証局５００が１つであるときを前提として、情報端末２００と通信をおこなうサイト４００の公開鍵証明書が信頼点証明書管理サーバ１００内のデータベース１０５に保存されていた場合について、公開鍵基盤を利用した通信を行えることを示したが、この実施の形態２では認証局５００が下位認証局５１０と上位認証局５２０からなっており、サイト４００の公開鍵を証明するための下位認証局５１０が発行した公開鍵証明書がデータベース１０５に保存されていない場合であっても、下位認証局５１０に対して上位認証局５２０の公開鍵証明書が信頼点証明書管理サーバ１００内のデータベース１０５に保存されている場合は、情報端末２００はサイト４００に対して公開鍵基盤を利用した通信を行うことが可能である点が異なる。

すなわち、図６は実施の形態２におけるシステム概念図であって、図１との差異はサイト４００に対して公開鍵証明書を発行している下位認証局５１０の公開鍵に対して公開鍵証明書を発行している上位の認証局５２０が存在していることである。

次に、情報端末２００がインターネット上のサイト４００と通信を行う前の準備段階について図７を用いて説明する。図７はインターネット上のサイトと通信を開始する前の準備段階の動作を示すシーケンス図である。ＳＴ２０１〜ＳＴ２０４はＳＴ００１〜ＳＴ００４と同様の動作なので説明を省略する。

次に、情報端末２００の使用者が下位認証局５１０は信頼点とせずに上位認証局５２０を信頼点としている場合について説明する。この場合、管理手段１０６を用いて上位認証局５２０から送付される上位認証局５２０の公開鍵証明書をデータベース１０５に保存する（ＳＴ２０５）。また、下位認証局５１０は自身が発行する公開鍵証明書に署名するために使用する公開鍵と秘密鍵のペアを生成する（ＳＴ２０６）。下位認証局５１０はこの公開鍵の公開鍵証書の発行申請を上位認証局５２０に対しておこなう（ＳＴ２０７）。この発行申請を受付けた上位認証局５２０はこの公開鍵に対する公開鍵証明書を発行し、下位認証局５１０に送付する（ＳＴ２０８）。ＳＴ２０９〜ＳＴ２１１まではＳＴ００６〜ＳＴ００８と同様の動作なので説明を省略する。

以上のように、ＳＴ２０１〜ＳＴ２１１までを行うことにより、信頼点証明書管理サーバ１００内のデータベース１０５内に上位認証局５２０の発行した上位公開鍵証明書が保管され、下位認証局５１０の発行した下位公開鍵証明書は保管されていない状態となっている。

次に図８を用いて、情報端末２００がサイト４００と公開鍵基盤を利用した通信をおこなう際の動作について説明する。図８は情報端末２００がサイト４００と公開鍵基盤による通信を行う際の動作を示すシーケンス図である。ＳＴ３０１〜ＳＴ３０６まではＳＴ１０１〜ＳＴ１０６と同様の動作なので説明を省略する。

ＳＴ３０６において下位認証局５１０の公開鍵証明書を要求された信頼点証明書管理サーバ１００は結果通知手段１０７を用いてデータベース１０５内を検索する（ＳＴ３０７）。検索の結果、下位公開鍵証明書を発見できないときは、上位公開鍵証明書入手手段１０８を用いて下位認証局５１０に公開鍵証明書を発行している上位認証局に対して、下位公開鍵証明書の送付要求をおこなう（ＳＴ３０８）。この要求を受けて、上位認証局５２０は信頼点証明書管理サーバ１００に自身の発行する下位公開鍵証明書を送付する（ＳＴ３０９）。この下位公開鍵証明書を受取った上位公開鍵証明書入手手段１０８は、この下位公開鍵証明書と下位公開鍵証明書の発行者名や鍵識別子等を結果通知手段１０７に送付し、結果通知手段１０７はこの送付に基づき、データベース１０５内を検索する。検索の結果、上位認証局５２０の公開鍵証明書を発見すると、データベース１０５内にあった上位公開鍵証明書と上位公開鍵証明書入手手段から送付された下位公開鍵証明書を情報端末２００に送付する（ＳＴ３１１）。情報端末２００は、証明書受取り手段２０４でこれらの上位公開鍵証明書を受取り、証明書検証手段２０２で、ＳＴ３０２でサイト４００から受取った公開鍵証明書と証明書受取り手段２０４で受取った上位公開鍵証明書の検証をおこなう（ＳＴ３１２）。検証の結果、いずれの公開鍵証明書も有効であるとみなされると、ＳＴ３０２で送付された公開鍵をサイト４００のものとみなして、その公開鍵を用いて発注情報などの送信が可能となる（ＳＴ３１３）。

この実施の形態によれば、情報端末２００から通信を行いたいサーバ４００に公開鍵証明書を発行している下位認証局５１０を信頼点としていない場合においても、下位認証局５１０に公開鍵証明書を発行している上位認証局５２０を信頼点として設定し、上位認証局５２０が発行する公開鍵証明書を、信頼点証明書管理サーバ１００内のデータベース１０５内に保管しておけば、公開鍵基盤を利用した通信が可能となる。

また、本実施例においてはサーバ４００に公開鍵証明書を発行している認証局の上位の認証局は１つだけであったが、２つ以上存在していてもよい。このような場合は、ＳＴ３０８〜ＳＴ３１０をデータベース内に上位の公開鍵証明書を発見するか、最上位の公開鍵証明書を得るまで繰り返すことにより、必要な公開鍵証明書の群を情報端末２００に送付することが可能である。また、信頼点証明書管理サーバ１００が最上位の公開鍵証明書までを得た結果、全ての公開鍵証明書をデータベース１０５内に発見できなかった場合は、発見できなかった旨を、情報端末２００に通知する。この場合、情報端末２００とサーバ４００は公開鍵基盤を利用した通信を行うことが出来ない。

本発明の実施形態１に係るシステムの全体構成を示す図である。本発明の実施形態に係る信頼点証明書管理サーバの内部構造を示す図である本発明の実施形態に係る情報端末の内部構造を示す図である。本発明の実施形態１の動作を示すシーケンス図である。本発明の実施形態１の動作を示すシーケンス図である。本発明の実施形態２に係るシステムの全体構成を示す図である。本発明の実施形態２の動作を示すシーケンス図である。本発明の実施形態２の動作を示すシーケンス図である。

符号の説明

１００信頼点証明書管理サーバ、１０４受付手段、１０５データベース、１０６データベース管理手段、１０７結果通知手段、１０８上位公開鍵証明書入手手段、２００情報端末、２０１証明書要求手段、２０２証明書検証手段、２０４証明書受取り手段、４００サイト、５１０下位認証局、５２０上位認証局

Claims

情報端末と、前記情報端末との暗号通信に用いられる第１の公開鍵を生成するサイトと、前記第１の公開鍵を証明する第１の公開鍵証明書に前記第１の公開鍵を含め自身の第１の電子署名を添付して発行し、前記第１の公開鍵とは異なる自身の鍵である第２の公開鍵を生成し該第２の公開鍵を証明する第２の公開鍵証明書に自身の第２の電子署名を添付して発行する前記サイトと異なる認証局と、前記認証局により発行された前記第２の公開鍵証明書を保存し管理する信頼点証明書管理サーバと、を備えた情報通信システムにおいて、
前記信頼点証明書管理サーバは、
前記認証局により発行された前記第２の公開鍵証明書を保存するデータベースと、
前記情報端末より前記第２の公開鍵証明書の送付要求を受付けるサーバ受付手段と、
前記送付要求に応じて前記データベース内を検索し、前記要求された第２の公開鍵証明書を発見すると該第２の公開鍵証明書を前記情報端末に送付する結果通知手段と、を備え、
前記情報端末は、
前記サイトへの送付要求に応じて該サイトから送付された前記第１の公開鍵証明書を受付ける第１の受付手段と、
前記信頼点証明書管理サーバへの送付要求に応じて該信頼点証明書管理サーバから送付された前記第２の公開鍵証明書を受付ける第２の受付手段と、
前記第２の公開鍵証明書に含まれる前記第２の公開鍵を用いて前記第１の公開鍵証明書に添付された前記認証局の前記第１の電子署名を検証し、前記第１の電子署名の検証ができた場合に前記第１の公開鍵証明書は前記認証局により発行されたものであるとする検証手段と、を備え、
前記第１の公開鍵証明書は前記認証局により発行されたものであると前記検証手段が確認した場合に、前記情報端末は、前記第１の公開鍵証明書に含まれる前記第１の公開鍵を用いて前記サイトとの暗号通信を開始することを特徴とする情報通信システム。