JP2002244557A

JP2002244557A - 暗号通信システムおよびそれに用いる認証方法

Info

Publication number: JP2002244557A
Application number: JP2001039572A
Authority: JP
Inventors: Naoki Kirimoto; 直樹桐本; Tatsuya Yamazaki; 達也山崎
Original assignee: ATR Adaptive Communications Research Laboratories
Current assignee: ATR Adaptive Communications Research Laboratories
Priority date: 2001-02-16
Filing date: 2001-02-16
Publication date: 2002-08-30

Abstract

(57)【要約】【課題】クライアントがサーバに対して自己の証明書
を送信しなくても、相互認証が可能な暗号通信システム
およびそれに用いる認証方法を提供する。【解決手段】暗号通信システム１０は、サーバ１と、
クライアントサーバ２Ａ，２Ｂ，２Ｃと、インターネッ
ト網３と、ＣＡＰｒｏｘｙ（Ｃｅｒｔｉｆｉｃａｔｅ
ＡｕｔｈｏｒｉｔｙＰｒｏｘｙ）４と、結合器５と
を備える。ＣＡＰｒｏｘｙ４は、インターネット網３と
結合器５との間に配置される。ＣＡＰｒｏｘｙ４は、
サーバ１からクライアントサーバ２Ａ，２Ｂ，２Ｃの電
子証明書の提出要求に応じて、クライアントサーバ２
Ａ，２Ｂ，２Ｃが電子証明書を保持しているか否かに拘
わらず、サーバ１に対してクライアントサーバ２Ａ，２
Ｂ，２Ｃが正規のサーバであることを示す自己の電子証
明書をサーバ１へ送信する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、暗号通信システ
ムに関し、特に、サーバからのクライアントの証明書の
要求に対して代理応答する暗号通信システムおよびそれ
に用いる認証方法に関するものである。

【０００２】

【従来の技術】現在、インターネットを用いて各種の情
報が通信されている。このインターネットを用いた通信
においては、図１０に示すように、２つのコンピュータ
１００，１１０は、ＯＳＩ（ＯｐｅｎＳｙｓｔｅｍ
Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ）参照モデル１３０を
用いて各種の情報を送受信する。コンピュータ１００
は、ケーブル、無線等の物理的接続１２０によってコン
ピュータ１１０とデータ等の各種の情報をやり取りす
る。ＯＳＩ参照モデル１３０は、物理層、データリンク
層、ネットワーク層、トランスポート層、セッション
層、プレゼンテーション層、およびアプリケーション層
の７層から成る。物理層が最下層であり、アプリケーシ
ョン層が最上層である。また、第１層から第４層までが
下位層であり、第５層から第７層が上位層である。コン
ピュータ１００がコンピュータ１１０と通信を行なうと
き、各層は、それぞれ、機能の異なるプロトコルである
が、互いに同じ層のやり取りを意識することによって結
果的に全体の通信プロトコルが成立する。

【０００３】図１１は、ＯＳＩ参照モデル１３０の各層
の機能を示したものである。最上層のアプリケーション
層は、コンピュータ１００，１１０を操作するユーザが
使用するアプリケーション（サービス）と下の層との橋
渡しを行なう。例えば、コンピュータ１００，１１０の
ユーザが通信すべきメッセージとして「こんにちは」と
キーボードから入力したとき、これを下の層に引渡した
り、逆に下の層からメッセージが届いた場合は、これを
アプリケーションとして認識する働きをする。データ通
信用のアプリケーションには、ファイル転送や電子メー
ルの送受信等、様々なものであるが、アプリケーション
層では、届いたデータがこれらのアプリケーションのう
ち、どのアプリケーションのものかを判断し、受信側で
該当する正しいアプリケーションに引渡す。また、送信
される情報では、送信先のどのアプリケーションへ渡さ
れるものかが明確になっている。従って、アプリケーシ
ョン層は、これらの交通整理を的確に行ない、情報自体
を認識し、制御する。

【０００４】プレゼンテーション層は、上の層から渡さ
れた情報を通信に適した形に変換して下の層に引渡した
り、下の層から渡された情報をアプリケーション層に適
した形に変換して上の層に引渡す。例えば、プレゼンテ
ーション層は、上述した「こんにちは」というメッセー
ジを符号して下の層に引渡し、下の層から渡された符号
化されたデータを「こんにちは」というメッセージに変
換して上の層へ渡す。セッション層は、プレゼンテーシ
ョン層で符号化されたデータを相手に送信する機能を果
たす。つまり、セッション層は、データを相手に送信す
る際、相手との通信経路を確立したり、通信方法を決定
する。

【０００５】トランスポート層は、通信情報の質を高め
るための通信制御を行なう。具体的には、トランスポー
ト層は、相手との通信においてデータが欠落したとき、
その欠落したデータを再送信してもらうように依頼す
る。ネットワーク層は、データを送信する際の送信元と
送信先とを決定する。つまり、ネットワーク層は、デー
タにヘッダを付加し、そのヘッダに送信元のアドレスと
送信先のアドレスとを書込む。データリンク層は、ネッ
トワーク層で設定された相手のアドレスに基づいて、デ
ータを次に送信すべき宛先を管理する。物理層は、デー
タリンク層から渡されたビット情報を実際に伝送するた
めの電気信号に変換したり、受信した電気信号をビット
情報に変換する。

【０００６】上述した７層から成るＯＳＩ参照モデル１
３０を用いて２つのコンピュータ１００，１１０間でデ
ータが通信される。このようなインターネットを用いた
データ通信においては、データのセキュリティが重要な
問題であり、データを暗号化して通信することが行なわ
れている。インターネットを用いた暗号通信で一般的に
使用されているのは、ＳＳＬ（ＳｅｃｕｒｅＳｏｃｋ
ｅｔＬａｙｅｒ）暗号通信である。ＳＳＬ暗号通信
は、公開鍵を基盤としたセキュリティ・インフラストラ
クチャーであるＰＫＩ（ＰｕｂｌｉｃＫｅｙＩｎｆ
ｒａｓｔｒｕｃｔｕｒｅ）の実装暗号化通信方式であ
る。そして、ＳＳＬ暗号通信においては、送信データの
暗号化に共通鍵暗号方式が用いられ、クライアントとサ
ーバとが送信データの暗号化に用いる共通鍵を共有する
ために公開鍵暗号方式が用いられている。

【０００７】インターネットによる通信において、不正
なアクセスなどによる重要データの漏洩・破壊を防ぐた
めにファイアウォールを設け、通過するデータを制御す
ることが行なわれている。しかし、ＳＳＬ暗号通信の場
合、ＯＳＩ参照モデルの上層部が暗号化されているた
め、暗号化されていない平文での通信に比べファイアウ
ォールで十分な通信制御を行なうことができない。この
ような問題を解決するために、”情報処理学会第５８回
（平成１１年前期）全国大会５Ｎ−６，３−３３３〜３
−３３４”には、インターネットとの暗号データとのや
り取りをサーバに代わって行なうＳＳＬ代理応答システ
ムが開示されている。図１２は、このＳＳＬ代理応答シ
ステムを示したものである。ＳＳＬ代理応答システム２
００は、インターネット２１０と、ファイアウォール２
２０と、代理サーバ２３０と、サーバ２４０とから成
る。ファイアウォール２２０は、インターネット２１０
とサーバ２４０との間に配置され、代理サーバ２３０は
ファイアウォール２２０に接続されている。インターネ
ット２１０からサーバ２４０へ暗号データが送信される
とき、ファイアウォール２２０は暗号データを代理サー
バ２３０へ送信する。そして、代理サーバ２３０は、受
信した暗号データを復号し、その復号した平文のデータ
をファイアウォール２２０へ送信する。ファイアウォー
ル２２０は、代理サーバ２３０からの平文のデータに対
して所定の制御を行なった後、サーバ２４０へ送信す
る。

【０００８】サーバ２４０からデータを送信するとき、
サーバ２４０は、平文のデータをファイアウォール２２
０へ送信する。ファイアウォール２２０は、受信したデ
ータに対して所定の制御を行なった後、データを代理サ
ーバ２３０へ送信する。代理サーバ２３０は、受信した
データを暗号化して暗号データをファイアウォール２２
０へ送信する。ファイアウォール２２０は、受信した暗
号データをインターネット２１０を介して送信する。

【０００９】このＳＳＬ代理応答システム２００におい
ては、代理サーバ２３０がサーバ２４０に代わってデー
タの暗号化および復号化を行なうことにより、ファイア
ウォール２２０によるアプリケーション層の通信制御を
可能にしている。また、暗号データの通信においては、
通信相手が正規の相手であることを相互に認証すること
がセキュリティの面から重要であるが、ＳＳＬ代理応答
システム２００においては、代理サーバ２３０は、証明
書および秘密鍵をサーバ２４０から譲り受け、サーバ２
４０に代わって暗号認証通信を行なう。

【００１０】また、暗号データの通信において相互認証
するとき、その相互認証に用いる証明書が漏洩したと
き、つまり、サーバの公開鍵やユーザの個人情報を暗号
化する秘密鍵（この秘密鍵は認証機関によって認証され
ている）が漏洩した場合、不正に侵入してきた相手と暗
号データを通信することになり、重要なデータが外部に
漏洩する。このような問題を解決するために、”コンピ
ュータセキュリティ７−４（２０００．１．２１）ｐ
１９〜２４”には、認証辞書（Ａｕｔｈｅｎｔｉｃａｔ
ｅｄＤｉｃｔｉｏｎａｒｙ）を用いて通信相手から送
信されてきた証明書が廃棄された証明書でないことを確
認するシステムが開示されている。この認証辞書は、証
明書が漏洩したことを示す証明書廃棄リスト（ＣＲＬ：
ＣｅｒｔｉｆｉｃａｔｅＲｅｖｏｃａｔｉｏｎＬｉ
ｓｔ）と等価な証明書の廃棄情報を持つものである。こ
のシステムにおいては、ＳＳＬ暗号通信における通信路
の確立時にサーバから送信された証明書の廃棄情報をク
ライアントが確認する。そして、クライアントは、受信
した証明書が廃棄情報に含まれていなければ、その証明
書に基づいて通信相手を認証する。

【００１１】

【発明が解決しようとする課題】しかし、上述した従来
の暗号データの通信方式においては、通信相手の認証
時、暗号データの通信を行なう送信者と受信者との間
で、自己の証明書を提示し合って認証するものである。
そして、証明書には、ユーザの個人情報も含まれるた
め、通信相手の認証時に個人情報が相手に知られるとい
う問題がある。図１２に示すＳＳＬ代理応答システム２
００においても、代理サーバ２３０が暗号認証通信を行
なうが、その際に送信するのはサーバ２４０の証明書で
ある。したがって、サーバ２４０の所有者の個人情報が
通信相手に知られる。

【００１２】また、従来の暗号データの通信方式におい
ては、通信相手の相互認証は証明書に基づいており、い
ずれか一方の秘密鍵が漏洩した場合、第三者のなりすま
しが危惧される。しかし、現在のＳＳＬ暗号通信の確立
段階で、証明書の有効性を検証する証明書廃棄リスト
（ＣＲＬ）との照合が行なわれていないため、第三者の
なりすましによる不正な暗号通信を防止できないという
問題がある。

【００１３】そこで、本発明は、かかる問題を解決する
ためになされたものであり、その目的は、クライアント
がサーバに対して自己の証明書を送信しなくても、相互
認証が可能な暗号通信システムおよびそれに用いる認証
方法を提供することである。

【００１４】また、本発明の別の目的は、さらに、漏洩
した証明書を送信した相手との通信を防止できる暗号通
信システムを提供することである。

【００１５】

【課題を解決するための手段】この発明による暗号通信
システムは、複数の層構造から成るプロトコルを用い
て、所定の暗号方式によって暗号化された暗号データの
通信を行なう暗号通信システムであって、データまたは
暗号データを送受信する第１のサーバと、第１のサーバ
との間でデータまたは暗号データを送受信する第２のサ
ーバと、第１のサーバと第２のサーバとの通信を中継す
る第３のサーバとを備え、第２のサーバの認証時、第３
のサーバは、第１のサーバからの第２のサーバの証明書
の要求に応じて、第２のサーバが正規のサーバであるこ
とを示す代理証明書を第２のサーバに代わって第１のサ
ーバへ送信する。

【００１６】この発明による暗号通信システムにおいて
は、第１のサーバが第２のサーバに対して証明書の送信
を要求したとき、第３のサーバは、第２のサーバに代わ
って代理証明書を第１のサーバへ送信する。

【００１７】したがって、この発明によれば、第２のサ
ーバは、個人情報を第１のサーバへ送信しなくても第１
のサーバとの間で暗号通信を行なうことができる。

【００１８】好ましくは、暗号通信システムにおいて、
第３のサーバは、自己の証明書を代理証明書として第１
のサーバへ送信する。

【００１９】第３のサーバは、第２のサーバの証明書の
代わりに自己の証明書を第１のサーバへ送信する。そし
て、第１のサーバは、代理証明書に基づいて第２のサー
バを正規のサーバとして認証する。

【００２０】したがって、この発明によれば、第２のサ
ーバは、自己の証明書を第１のサーバへ送信しなくても
正規のサーバとして第１のサーバとの間で暗号通信を行
なうことができる。

【００２１】好ましくは、暗号通信システムにおいて、
第３のサーバは、第１のサーバから受信した第２のサー
バの証明書の要求を第２のサーバへ送信し、第２のサー
バから第２のサーバの証明書を受信すると代理証明書を
第１のサーバへ送信する。

【００２２】第２のサーバは、第１のサーバからの第２
のサーバの証明書の送信要求を受取り、自己の証明書を
第３のサーバへ送信する。そうすると、第３のサーバ
は、第２のサーバから受信した証明書に代えて代理証明
書を第１のサーバへ送信する。

【００２３】したがって、この発明によれば、第２のサ
ーバが証明書を保持している場合でも第２のサーバの個
人情報を第１のサーバに公表せずに第１のサーバと第２
のサーバとの間で暗号通信を行なうことができる。

【００２４】好ましくは、暗号通信システムにおいて、
第３のサーバは、第２のサーバの証明書の要求を第２の
サーバへ送信し、第２のサーバが証明書を保持しないこ
とを示す情報を第２のサーバから受信すると代理証明書
を第１のサーバへ送信する。

【００２５】第２のサーバは、第１のサーバからの第２
のサーバの証明書の送信要求を受取り、証明書を保持し
ていないことを第３のサーバへ送信する。そうすると、
第３のサーバは、自己が保持する代理証明書を第１のサ
ーバへ送信する。

【００２６】したがって、この発明によれば、第２のサ
ーバが証明書を保持していない場合でも、正規のサーバ
として第１のサーバとの間で暗号通信を行なうことがで
きる。

【００２７】好ましくは、暗号通信システムにおいて、
第３のサーバは、第１のサーバから受信した第１のサー
バの証明書を証明書廃棄リストと照合し、第１のサーバ
の証明書が廃棄されているとき第１のサーバの証明書が
無効であることを示す情報を第１のサーバへ送信する。

【００２８】第１のサーバの証明書が証明書廃棄リスト
に含まれるとき、第１のサーバへ証明書の無効通知が送
信される。

【００２９】したがって、この発明によれば、不正な相
手との暗号通信を防止できる。好ましくは、暗号通信シ
ステムにおいて、第３のサーバは、第１のサーバから受
信した第１のサーバの証明書を証明書廃棄リストと照合
し、第１のサーバの証明書が廃棄されていないことを確
認すると代理証明書を第１のサーバへ送信する。

【００３０】第２のサーバの証明書の送信を要求した第
１のサーバが正規であることが確認されると、第３のサ
ーバは、代理証明書を第１のサーバへ送信する。

【００３１】したがって、この発明によれば、暗号通信
におけるセキュリティを向上させることができる。

【００３２】好ましくは、第３のサーバは、第１のサー
バと第２のサーバとの間の通信を制御する通信制御部
と、通信制御部を介して受取った第１のサーバの証明書
を証明書廃棄リストと照合する証明書照合部と、証明書
照合部からの照合結果に基づいて、第１のサーバを認証
し、または第１のサーバの証明書を無効と判定する認証
部と、通信制御部を介して第２のサーバの証明書または
第２のサーバが証明書を保持しない情報を受取ると、代
理証明書を第１のサーバへ送信する代理応答部とを含
む。

【００３３】第３のサーバは、第１のサーバと第２のサ
ーバとの間の通信を制御するとともに、証明書の証明書
廃棄リストとの照合、証明書の認証、および代理応答を
行なう。

【００３４】したがって、この発明によれば、暗号通信
を行なう２つのサーバの間に、代理応答等を行なうサー
バを設けることによって個人情報を隠匿して暗号通信を
行なうことができる。

【００３５】また、この発明による認証方法は、第１の
サーバと第２のサーバとの間における認証方法であっ
て、第２のサーバの証明書の送信要求を第１のサーバか
ら受信する第１のステップと、第２のサーバの証明書に
代えて代理証明書を第１のサーバへ送信する第２のステ
ップとを備える。

【００３６】この発明による認証方法においては、第１
のサーバからの証明書の送信要求に対して代理証明書が
第１のサーバへ送信されて第２のサーバの認証が行なわ
れる。

【００３７】したがって、この発明によれば、個人情報
を相手に公開せずとも相互認証を行なうことができる。

【００３８】好ましくは、第２のステップにおいて、代
理証明書は、第２のサーバが証明書を保持するか否かに
拘わらず第１のサーバへ送信される。

【００３９】第２のサーバが認証機関によって認証され
た証明書を保持しているか否かに関係なく代理証明書が
第１のサーバへ送信され、第２のサーバの認証が行なわ
れる。

【００４０】したがって、この発明によれば、証明書を
保持しないサーバでも正規のサーバとして暗号通信を行
なうことができる。

【００４１】

【発明の実施の形態】以下、本発明の実施の形態につい
て図面を参照しながら詳細に説明する。なお、図中同一
または相当部分には同一符号を付してその説明は繰返さ
ない。

【００４２】図１は、本発明による暗号通信システムの
概略ブロック図である。暗号通信システム１０は、サー
バ１と、クライアントサーバ２Ａ，２Ｂ，２Ｃと、イン
ターネット網３と、ＣＡＰｒｏｘｙ（Ｃｅｒｔｉｆｉ
ｃａｔｅＡｕｔｈｏｒｉｔｙＰｒｏｘｙ）４と、結
合器５とを備える。サーバ１は、インターネット網３に
接続される。クライアントサーバ２Ａ，２Ｂ，２Ｃは、
結合器５に接続される。ＣＡＰｒｏｘｙ４は、インタ
ーネット網３と結合器５との間に配置される。

【００４３】サーバ１は、後述する方法によってインタ
ーネット網３、ＣＡＰｒｏｘｙ４、および結合器５を
介してクライアントサーバ２Ａ，２Ｂ，２Ｃへデータま
たは暗号データを送信し、またはクライアントサーバ２
Ａ，２Ｂ，２Ｃからデータまたは暗号データを受信す
る。インターネット網３は、サーバ１からのデータまた
は暗号データをＣＡＰｒｏｘｙ４へ送信し、ＣＡＰ
ｒｏｘｙ４からのデータまたは暗号データをサーバ１へ
送信する。

【００４４】ＣＡＰｒｏｘｙ４は、インターネット網
３からのデータまたは暗号データを結合器５を介してク
ライアントサーバ２Ａ，２Ｂ，２Ｃへ送信する。また、
ＣＡＰｒｏｘｙ４は、クライアントサーバ２Ａ，２Ｂ，
２Ｃからのデータまたは暗号データを結合器５を介して
受信し、その受信したデータまたは暗号データをインタ
ーネット網３を介してサーバ１へ送信する。さらに、Ｃ
ＡＰｒｏｘｙ４は、サーバ１から受信した電子証明書
を証明書廃棄リスト（ＣＲＬ）と照合し、受信した電子
証明書がＣＲＬに含まれていないとき、受信した電子証
明書に基づいてサーバ１を正規の通信相手として認証す
る。また、さらに、ＣＡＰｒｏｘｙ４は、サーバ１か
らクライアントサーバ２Ａ，２Ｂ，２Ｃの電子証明書の
提出要求に応じて、自己の電子証明書をサーバ１へ送信
する。即ち、ＣＡＰｒｏｘｙ４は、クライアントサー
バ２Ａ，２Ｂ，２Ｃが電子証明書を保持しているか否か
に拘わらず、サーバ１に対してクライアントサーバ２
Ａ，２Ｂ，２Ｃが正規のサーバであることを示す自己の
電子証明書を送信する。つまり、ＣＡＰｒｏｘｙ４
は、クライアントサーバ２Ａ，２Ｂ，２Ｃに代わってサ
ーバ１に対して電子証明書の代理応答を行なう。これに
より、クライアントサーバ２Ａ，２Ｂ，２Ｃは、自己の
電子証明書をサーバ１へ送信しなくても、相互認証がで
き、サーバ１との間で通信路を確立できる。

【００４５】結合器５は、ＣＡＰｒｏｘｙ４からのデ
ータまたは暗号データをクライアントサーバ２Ａ，２
Ｂ，２Ｃの各々へ振り分ける。

【００４６】図２は、サーバ１、クライアントサーバ２
Ａ，２Ｂ，２Ｃ、およびＣＡＰｒｏｘｙ４の機能ブロ
ックを示したものである。サーバ１は、Ｒｅｃｏｒｄ
Ｐｒｏｔｏｃｏｌ部１１と、ＨａｎｄｓｈａｋｅＰｒ
ｏｔｏｃｏｌ部１２と、ＣｈａｎｇｅＣｉｐｈｅｒ
ＳｐｅｃＰｒｏｔｏｃｏｌ部１３と、ＡｌｅｒｔＰｒ
ｏｔｏｃｏｌ部１４と、ＡｐｐｌｉｃａｔｉｏｎＤａ
ｔａＰｒｏｔｏｃｏｌ部１５と、アプリケーション部
１６とを含む。ＲｅｃｏｒｄＰｒｏｔｏｃｏｌ部１
１、ＨａｎｄｓｈａｋｅＰｒｏｔｏｃｏｌ部１２、Ｃ
ｈａｎｇｅＣｉｐｈｅｒＳｐｅｃＰｒｏｔｏｃｏ
ｌ部１３、ＡｌｅｒｔＰｒｏｔｏｃｏｌ部１４、およ
びＡｐｐｌｉｃａｔｉｏｎＰｒｏｔｏｃｏｌ部１５は
ＳＳＬプロトコルを構成する。ＳＳＬプロトコルは、図
１０に示したセッション層のプロトコルであり、アプリ
ケーション部１６は、図１０に示したセッション層より
も上位のプロトコルである。

【００４７】ＲｅｃｏｒｄＰｒｏｔｏｃｏｌ部１１
は、アプリケーション部１６からのデータを圧縮／暗号
化して、クライアントサーバ２Ａ，２Ｂ，２Ｃへ送信す
る。また、クライアント２Ａ，２Ｂ，２Ｃから受信した
暗号データを復号化／伸張してアプリケーション部１６
へ引渡す。ＨａｎｄｓｈａｋｅＰｒｏｔｏｃｏｌ部１
２は、暗号化アルゴリズム、暗号鍵、電子証明書など、
暗号データの通信を開始するために必要なパラメータを
通信相手と交渉し、決定する。

【００４８】ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃ
Ｐｒｏｔｏｃｏｌ部１３は、ＨａｎｄｓｈａｋｅＰｒ
ｏｔｏｃｏｌ部１２で決定された、新しい暗号化通信パ
ラメータの利用開始を通信相手に通知し、自らも利用を
開始する。ＡｌｅｒｔＰｒｏｔｏｃｏｌ部１４は、通
信中に発生したイベントやエラーを通信相手に通知す
る。ＡｐｐｌｉｃａｔｉｏｎＤａｔａＰｒｏｔｏｃ
ｏｌ部１５は、現在、有効な暗号化通信パラメータに従
って、アプリケーションデータを透過的に送受信する。
アプリケーション部１６は、ＳＳＬプロトコルのＡｐｐ
ｌｉｃａｔｉｏｎＤａｔａＰｒｏｔｏｃｏｌ部１５か
らのデータを受取って、その受取ったデータを処理す
る。また、アプリケーション部１６は、新たに作成した
データをＳＳＬプロトコルのＡｐｐｌｉｃａｔｉｏｎ
ＤａｔａＰｒｏｔｏｃｏｌ部１５へ引渡す。

【００４９】クライアントサーバ２Ａ，２Ｂ，２Ｃは、
ＲｅｃｏｒｄＰｒｏｔｏｃｏｌ部２１と、Ｈａｎｄｓ
ｈａｋｅＰｒｏｔｏｃｏｌ部２２と、Ｃｈａｎｇｅ
ＣｉｐｈｅｒＳｐｅｃＰｒｏｔｏｃｏｌ部２３と、
ＡｌｅｒｔＰｒｏｔｏｃｏｌ部２４と、Ａｐｐｌｉｃ
ａｔｉｏｎＤａｔａＰｒｏｔｏｃｏｌ部２５と、ア
プリケーション部２６とを含む。ＲｅｃｏｒｄＰｒｏ
ｔｏｃｏｌ部２１、ＨａｎｄｓｈａｋｅＰｒｏｔｏｃ
ｏｌ部２２、ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃ
Ｐｒｏｔｏｃｏｌ部２３、ＡｌｅｒｔＰｒｏｔｏｃｏ
ｌ部２４、およびＡｐｐｌｉｃａｔｉｏｎＤａｔａ
Ｐｒｏｔｏｃｏｌ部２５は、ＳＳＬプロトコルを構成す
る。ＲｅｃｏｒｄＰｒｏｔｏｃｏｌ部２１、Ｈａｎｄ
ｓｈａｋｅＰｒｏｔｏｃｏｌ部２２、Ｃｈａｎｇｅ
ＣｉｐｈｅｒＳｐｅｃＰｒｏｔｏｃｏｌ部２３、Ａ
ｌｅｒｔＰｒｏｔｏｃｏｌ部２４、およびＡｐｐｌｉ
ｃａｔｉｏｎＤａｔａＰｒｏｔｏｃｏｌ部２５は、
それぞれ、サーバ１のＲｅｃｏｒｄＰｒｏｔｏｃｏｌ
部１１、ＨａｎｄｓｈａｋｅＰｒｏｔｏｃｏｌ部１
２、ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃＰｒｏｔ
ｏｃｏｌ部１３、ＡｌｅｒｔＰｒｏｔｏｃｏｌ部１
４、およびＡｐｐｌｉｃａｔｉｏｎＤａｔａＰｒｏｔ
ｏｃｏｌ部１５と同じ機能を果たす。また、アプリケー
ション部２６は、サーバ１のアプリケーション部１６に
対応する。

【００５０】ＣＡＰｒｏｘｙ４は、通信プロトコルキ
ャプチャー部４１と、ＣＲＬチェック部４２と、認証部
４３と、代理応答部４４とを含む。通信プロトコルキャ
プチャー部４１は、サーバ１とクライアントサーバ２
Ａ，２Ｂ，２Ｃとの間で行なわれる通信を監視するとと
もに、ＣＲＬチェック部４２、認証部４３、および代理
応答部４４で処理すべき通信プロトコルをそれぞれに振
り分ける。ＣＲＬチェック部４２は、第三者である認証
機関（図示せず）が作成した証明書廃棄リスト（ＣＲ
Ｌ）を認証機関から取得して保持しており、通信プロト
コルキャプチャー部４１がサーバ１から受信したサーバ
１の電子証明書を受け、サーバ１の電子証明書を証明書
廃棄リストと照合し、その照合結果を通信プロトコルキ
ャプチャー部４１へ出力する。なお、ＣＲＬチェック部
４２は、認証機関から証明書廃棄リストを定期的に取得
し、証明書廃棄リストの更新を行なう。

【００５１】認証部４３は、ＣＡＰｒｏｘｙ４の電子
証明書を保持しており、サーバ１からクライアントサー
バ２Ａ，２Ｂ，２Ｃの電子証明書の提出を要求される
と、クライアントサーバ２Ａ，２Ｂ，２ＣはＣＡＰｒ
ｏｘｙ４の支配下にあるクライアントサーバであること
の認証を行なう。この場合、認証部４３は、クライアン
トサーバ２Ａ，２Ｂ，２Ｃの電子証明書に代えてＣＡ
Ｐｒｏｘｙ４の電子証明書を代理応答部４４へ出力す
る。代理応答部４４は、クライアントサーバ２Ａ，２
Ｂ，２Ｃから”ＣｌｉｅｎｔＣｅｒｔｉｆｉｃａｔ
ｅ”メッセージまたは”ＮｏＣｅｒｔｉｆｉｃａｔ
ｅ”メッセージを通信プロトコルキャプチャー部４１を
介して受信すると、認証部４３から受取ったＣＡＰｒ
ｏｘｙ４の電子証明書をクライアントサーバ２Ａ，２
Ｂ，２Ｃに代わってサーバ１へ送信する。

【００５２】なお、サーバ１およびクライアントサーバ
２Ａ，２Ｂ，２ＣにおけるＳＳＬプロトコルはＩＥＴＦ
（ＩｎｔｅｒｎａｔｉｏｎａｌＥｎｇｉｎｅｅｒｉｎ
ｇＴａｓｋＦｏｒｃｅ）によって公開されている機能
と同じである。

【００５３】図３は、電子証明書の構成を示す概略ブロ
ック図である。電子証明書５０は、バージョン５１と、
シリアル番号５２と、証明書発行者５３と、発行者ユニ
ーク識別子５４と、証明対象ユーザ５５と、ユーザユニ
ーク識別子５６と、証明対象公開鍵アルゴリズム５７
と、証明対象公開鍵５８と、証明書有効期限５９と、証
明書拡張６０と、署名アルゴリズム６１と、署名６２と
を含む。バージョン５１は、証明書５０の構成要素を規
定するものである。シリアル番号５２は、その証明書が
何番目に発行されたかを示す番号である。発行者ユニー
ク識別子５４は、証明書を発行する認証機関を識別する
ための情報であり、認証機関に固有のＩＤが書込まれ
る。証明対象ユーザ５５は、認証機関に自己の公開鍵の
認証を依頼するユーザの名前である。ユーザユニーク識
別子５６は、認証機関に自己の公開鍵の認証を依頼する
ユーザを識別するための情報であり、ユーザＩＤが書込
まれる。証明対象公開鍵アルゴリズム５７は、ユーザが
認証を依頼した公開鍵を生成するためのアルゴリズムで
ある。証明対象公開鍵５８は、ユーザに依頼されて、認
証機関が認証する公開鍵である。証明書有効期限５９
は、電子証明書５０が有効である期間である。証明書拡
張６０は、将来、各種の情報を電子証明書に格納するた
めの枠組みを与えるものである。署名アルゴリズム６１
は、認証機関が署名するとき、つまり、電子証明書５０
のバージョン５１から署名アルゴリズム６１の各情報を
認証機関の秘密鍵で暗号化し、または認証機関の復号鍵
で復号するときのアルゴリズムである。署名６２は、認
証機関が電子証明書５０のバージョン５１から署名アル
ゴリズム６１の各情報を自己の秘密鍵で暗号化している
ことを示す情報である。暗号通信システム１０は、デー
タを暗号化する共通鍵をサーバ１とクライアントサーバ
２Ａ，２Ｂ，２Ｃとの間で共有するために公開鍵暗号方
式を用いている。従って、サーバ１、およびクライアン
トサーバ２Ａ，２Ｂ，２Ｃは、自己の公開鍵５８を第三
者である認証機関へ登録し、その登録によって自己の公
開鍵５８を認証してもらう。そして、サーバ１、および
クライアントサーバ２Ａ，２Ｂ，２Ｃは、自己の公開鍵
５８を認証機関で認証してもらった電子証明書５０を保
持し、その電子証明書５０によって自己が認証機関によ
って認証された正規のサーバであることを証明する。証
明対象ユーザ５５およびユーザユニーク識別子５６は、
ユーザの個人情報に該当する部分である。

【００５４】従って、電子証明書５０を受信したサーバ
１等は、電子証明書５０を認証機関が発行した公開鍵に
よって復号すれば、電子証明書５０を送信した相手が正
規のサーバであるか否かを判別できる。

【００５５】図４〜図６は、サーバ１とクライアントサ
ーバ２Ａ，２Ｂ，２Ｃとの間のＳＳＬ暗号通信における
セッション確立のフローチャートである。まず、図４に
示すフローチャートについて説明する。サーバ１とクラ
イアントサーバ２Ａ，２Ｂ，２Ｃとの間の通信が開始さ
れると（ステップＳ１００）、クライアントサーバ２
Ａ，２Ｂ，２ＣのＨａｎｄｓｈａｋｅＰｒｏｔｏｃｏ
ｌ部２２は、”ＣｌｉｅｎｔＨｅｌｌｏ”メッセージを
ＲｅｃｏｒｄＰｒｏｔｏｃｏｌ部２１を介して送信す
る（ステップＳ１０２）。この”ＣｌｉｅｎｔＨｅｌｌ
ｏ”メッセージは、通信プロトコルのバージョン、セッ
ションＩＤ、暗号化アルゴリズム等の候補を含む。ＣＡ
Ｐｒｏｘｙ４の通信プロトコルキャプチャー部４１
は、クライアントサーバ２Ａ，２Ｂ，２Ｃからの”Ｃｌ
ｉｅｎｔＨｅｌｌｏ”メッセージを受信し、その受信し
た”ＣｌｉｅｎｔＨｅｌｌｏ”メッセージをサーバ１へ
送信する。サーバ１のＨａｎｄｓｈａｋｅＰｒｏｔｏ
ｃｏｌ部１２は、ＲｅｃｏｒｄＰｒｏｔｏｃｏｌ部１１
を介して”ＣｌｉｅｎｔＨｅｌｌｏ”メッセージを受信
する（ステップＳ１０４）。そして、Ｈａｎｄｓｈａｋ
ｅＰｒｏｔｏｃｏｌ部１２は、受信した”Ｃｌｉｅｎ
ｔＨｅｌｌｏ”メッセージに含まれるプロトコルバージ
ョン、セッションＩＤ、および暗号アルゴリズムの候補
から１つのプロトコルバージョン、セッションＩＤ、お
よび暗号アルゴリズムを選択し、その選択したプロトコ
ルバージョン、セッションＩＤ、および暗号アルゴリズ
ムを”ＳｅｖｅｒＨｅｌｌｏ”メッセージに含めてクラ
イアントサーバ２Ａ，２Ｂ，２Ｃへ送信する（ステップ
Ｓ１０６）。

【００５６】ＣＡＰｒｏｘｙ４の通信プロトコルキャ
プチャー部４１は、サーバ１からの”ＳｅｒｖｅｒＨｅ
ｌｌｏ”メッセージを受信し、その受信した”Ｓｅｒｖ
ｅｒＨｅｌｌｏ”メッセージをクライアントサーバ２
Ａ，２Ｂ，２Ｃへ送信する。クライアントサーバ２Ａ，
２Ｂ，２ＣのＨａｎｄｓｈａｋｅＰｒｏｔｏｃｏｌ部
２２は、”ＳｅｒｖｅｒＨｅｌｌｏ”メッセージをＲｅ
ｃｏｒＰｒｏｔｏｃｏｌ部２１を介して受信し、”Ｓ
ｅｒｖｅｒＨｅｌｌｏ”メッセージに基づいてサーバ１
が選択したプロトコルバージョン、セッションＩＤ、お
よび暗号アルゴリズムを確認する（ステップＳ１０
８）。これによって、サーバ１とクライアントサーバ２
Ａ，２Ｂ，２Ｃとの間の暗号通信方式が決定される。

【００５７】その後、サーバ１のＨａｎｄｓｈａｋｅ
Ｐｒｏｔｏｃｏｌ部１２は、”ＳｅｒｖｅｒＣｅｒｔｉ
ｆｉｃａｔｅ”メッセージをＲｅｃｏｒｄＰｒｏｔｏ
ｃｏｌ部１１を介して送信する（ステップＳ１１０）。
なお、この”ＳｅｒｖｅｒＣｅｒｔｉｆｉｃａｔｅ”
は、サーバ１の電子証明書であり、通信関連の国際標準
機構であるＩＴＵ（ＩｎｔｅｒｎａｔｉｏｎａｌＴｅ
ｌｅｃｏｍｍｕｎｉｃａｔｉｏｎＵｎｉｏｎ）で標準
化されたＸ．５０９ｖ３による標準仕様に従って作成さ
れている。以下に述べる”ＣｌｉｅｎｔＣｅｒｔｉｆｉ
ｃａｔｅ”も同様である。ＣＡＰｒｏｘｙ４の通信プ
ロトコルキャプチャー部４１は、サーバ１からの”Ｓｅ
ｒｖｅｒＣｅｒｔｉｆｉｃａｔｅ”を受信し、その受信
した”ＳｅｒｖｅｒＣｅｒｔｉｆｉｃａｔｅ”メッセー
ジをＣＲＬチェック部４２へ出力する。ＣＲＬチェック
部４２は、”ＳｅｒｖｅｒＣｅｒｔｉｆｉｃａｔｅ”メ
ッセージを受取り、サーバ１の電子証明書を証明書廃棄
リスト（ＣＲＬ）と照合し、サーバ１の電子証明書が証
明書廃棄リスト（ＣＲＬ）に含まれるか否かをチェック
する。そして、ＣＲＬチェック部４２は、照合結果を通
信プロトコルキャプチャー部４１へ出力する（ステップ
Ｓ１１２）。

【００５８】サーバ１の電子証明書が証明書廃棄リスト
（ＣＲＬ）に含まれる場合、通信プロトコルキャプチャ
ー部４１は、サーバ１の電子証明書が無効であることを
示す無効通知をサーバ１へ送信する（ステップＳ１１
４）。そして、サーバ１のＨａｎｄｓｈａｋｅＰｒｏ
ｔｏｃｏｌ部１２は、ＲｅｃｏｒｄＰｒｏｔｏｃｏｌ
部１１を介して無効通知を受信し（ステップＳ１１
６）、サーバ１とクライアントサーバ２Ａ，２Ｂ，２Ｃ
との通信は終了する（ステップＳ１５４）。つまり、サ
ーバ１は、正規のサーバではないと判断されたので、サ
ーバ１とクライアントサーバ２Ａ，２Ｂ，２Ｃとの通信
は終了し、クライアントサーバ２Ａ，２Ｂ，２Ｃの重要
な情報が不正なサーバへ漏洩するのを防止できる。

【００５９】ステップＳ１１２において、サーバ１の電
子証明書が証明書廃棄リスト（ＣＲＬ）に含まれていな
いと判断されたとき、ＣＡＰｒｏｘｙ４の通信プロト
コルキャプチャー部４１は、サーバ１から受信した電子
証明書をクライアントサーバ２Ａ，２Ｂ，２Ｃへ送信し
（ステップＳ１１８）、クライアントサーバ２Ａ，２
Ｂ，２ＣのＨａｎｄｓｈａｋｅＰｒｏｔｏｃｏｌ部２
２は、ＲｅｃｏｒｄＰｒｏｔｏｃｏｌ部２１を介して
サーバ１の電子証明書を受信する（ステップＳ１２
０）。これによって、サーバ１は正規のサーバであるこ
とが認証されるとともに、クライアントサーバ２Ａ，２
Ｂ，２Ｃは、サーバ１の公開鍵を取得する。

【００６０】そして、サーバ１のＨａｎｄｓｈａｋｅ
Ｐｒｏｔｏｃｏｌ部１２は、クライアントサーバ２Ａ，
２Ｂ，２Ｃに対して電子証明書の送信を要求するか否か
を判定する（ステップＳ１２２）。電子証明書の送信を
要求しないとき、図５に示すステップＳ１３２へ移行す
る。また、ＨａｎｄｓｈａｋｅＰｒｏｔｏｃｏｌ部１
２は、電子証明書の提出を要求すると判定したとき、”
ＣｅｒｔｉｆｉｃａｔｅＲｅｑｕｅｓｔ”をＲｅｃｏ
ｒｄＰｒｏｔｏｃｏｌ部１１を介して送信し、クライ
アントサーバ２Ａ，２Ｂ，２ＣのＨａｎｄｓｈａｋｅ
Ｐｒｏｔｏｃｏｌ部２２は、ＣＡＰｒｏｘｙ４および
ＲｅｃｏｒｄＰｒｏｔｏｃｏｌ部２１を介して”Ｃｅ
ｒｔｉｆｉｃａｔｅＲｅｑｕｅｓｔ”を受信し、それ
に対して”ＮｏＣｅｒｔｉｆｉｃａｔｅ”メッセージ
をＣＡＰｒｐｘｙ４へ送信する（ステップＳ１２
４）。

【００６１】次に、図５に示すフローチャートについて
説明する。ＣＡＰｒｏｘｙ４の通信プロトコルキャプ
チャー部４１は、クライアントサーバ２Ａ，２Ｂ，２Ｃ
から”ＮｏＣｅｒｔｉｆｉｃａｔｅ”メッセージを受
信し、その受信した”ＮｏＣｅｒｔｉｆｉｃａｔｅ”メ
ッセージを認証部４３および代理応答部４４へ出力す
る。そして、認証部４３は、”ＮｏＣｅｒｔｉｆｉｃ
ａｔｅ”メッセージを受取ると、保持しているＣＡＰ
ｒｏｘｙ４の電子証明書を代理応答部４４へ出力する。
代理応答部４４は、通信プロトコルキャプチャー部４１
からの”ＮｏＣｅｒｔｉｆｉｃａｔｅ”メッセージを受
けると、サーバ１に対して代理応答するか否かを判定す
る（ステップＳ１２６）。代理応答部４４が代理応答し
ないと判定したとき、ステップＳ１５４へ移行し、通信
は終了する。代理応答部４４は、代理応答すると判定す
ると、認証部４３から入力されたＣＡＰｒｐｘｙ４の
電子証明書を通信プロトコルキャプチャー部４１を介し
てサーバ１へ送信する（ステップＳ１２８）。

【００６２】サーバ１のＨａｎｄｓｈａｋｅＰｒｏｔ
ｏｃｏｌ部１２は、ＲｅｃｏｒｄＰｒｏｔｏｃｏｌ部１
１を介してＣＡＰｒｏｘｙ４からの電子証明書を受信
し、その受信した電子証明書に基づいてＣＡＰｒｏｘ
ｙ４が正規のサーバであることを認証するとともに、ク
ライアントサーバ２Ａ，２Ｂ，２Ｃとの暗号通信に用い
る公開鍵を取得する（ステップＳ１３０）。この場合、
ＨａｎｄｓｈａｋｅＰｒｏｔｏｃｏｌ部１２は、形式的
にはＣＡＰｒｏｘｙ４を正規のサーバとして認証する
が、ＣＡＰｒｏｘｙ４はクライアントサーバ２Ａ，２
Ｂ，２Ｃに代わって電子証明書をサーバ１へ送信してい
るので、ＨａｎｄｓｈａｋｅＰｒｏｔｏｃｏｌ部１２
は、実質的にはクライアントサーバ２Ａ，２Ｂ，２Ｃを
正規のサーバとして認証する。また、ＣＡＰｒｏｘｙ
４は、クライアントサーバ２Ａ，２Ｂ，２Ｃが電子証明
書を保持しない場合でもクライアントサーバ２Ａ，２
Ｂ，２Ｃに代わって自己の電子証明書をサーバ１へ送信
するので、認証機関によって認証された電子証明書を保
持しないクライアントでも正規のサーバとしてサーバ１
との暗号通信が可能になる。

【００６３】ステップＳ１２２で”Ｎｏ”が選択された
後、またはステップＳ１３０の後、クライアントサーバ
２Ａ，２Ｂ，２ＣのＨａｎｄｓｈａｋｅＰｒｏｔｏｃ
ｏｌ部２２は、４８バイトの乱数を発生させ、その発生
させた乱数をＲｅｃｏｒｄＰｒｏｔｏｃｏｌ部２１へ出
力する。ＲｅｃｏｒｄＰｒｏｔｏｃｏｌ部２１は、入
力された乱数をサーバ１の公開鍵Ｐａで暗号化し、その
暗号化した乱数を”ＣｌｉｅｎｔＫｅｙＥｘｃｈａｎｇ
ｅ”メッセージとしてサーバ１へ送信する（ステップＳ
１３２）。ＨａｎｄｓｈａｋｅＰｒｏｔｏｃｏｌ部２
２が発生した乱数は、サーバ１とクライアントサーバ２
Ａ，２Ｂ，２Ｃとの間でデータを暗号通信する際の共通
鍵を生成するためのものであり、Ｈａｎｄｓｈａｋｅ
Ｐｒｏｔｏｃｏｌ部２２は、発生した乱数を用いて共通
鍵を生成する。

【００６４】一方、サーバ１のＲｅｃｏｒｄＰｒｏｔ
ｏｃｏｌ部１１は、ＣＡＰｒｏｃｙ４を介して”Ｃｌ
ｉｅｎｔＫｅｙＥｘｃｈａｎｇｅ”メッセージを受信
し、暗号化された乱数を秘密鍵Ｓａで復号する（ステッ
プＳ１３４）。そして、ＲｅｃｏｒｄＰｒｏｔｏｃｏ
ｌ部１１は、復号した乱数をＨａｎｄｓｈａｋｅＰｒ
ｏｔｏｃｏｌ部１２へ出力する。Ｈａｎｄｓｈａｋｅ
Ｐｒｏｔｏｃｏｌ部１２は、入力された４８バイトの乱
数を用いて共通鍵を生成する。

【００６５】その後、クライアントサーバ２Ａ，２Ｂ，
２ＣのＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃＰｒｏｔ
ｏｃｏｌ部２３は、ステップＳ１３６までにサーバ１と
クライアント２Ａ，２Ｂ，２Ｃとの間で合意された暗号
通信方式に同意し、生成した共通鍵を認めることを示
す”ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃ”メッセージを
生成してＲｅｃｏｒｄＰｒｏｔｏｃｏｌ部２１へ出力
する。ＲｅｃｏｒｄＰｒｏｔｏｃｏｌ部２１は、共通鍵
ＫＰａによって”ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃ”
メッセージを暗号化した｛ＣｈａｎｇｅＣｉｐｈｅｒＳ
ｐｅｃ｝ＫＰａを生成してクライアントサーバ２Ａ，２
Ｂ，２Ｃへ送信する（ステップＳ１３６）。

【００６６】サーバ１のＲｅｃｏｒｄＰｒｏｔｏｃｏ
ｌ部１１は、ＣＡＰｒｏｘｙ４を介して｛Ｃｈａｎｇ
ｅＣｉｐｈｅｒＳｐｅｃ｝ＫＰａを受信し、共通鍵ＫＰ
ａを用いて｛ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃ｝ＫＰ
ａを復号する。そして、ＲｅｃｏｒｄＰｒｏｔｏｃｏ
ｌ部１１は、復号した”ＣｈａｎｇｅＣｉｐｈｅｒＳｐ
ｅｃ”メッセージをＣｈａｎｇｅＣｉｐｈｅｒＳｐ
ｅｃ部１３へ出力する。ＣｈａｎｇｅＣｉｐｈｅｒ
ＳｐｅｃＰｒｏｔｏｃｏｌ部１３は、”Ｃｈａｎｇｅ
ＣｉｐｈｅｒＳｐｅｃ”メッセージを受けて、クライア
ントサーバ２Ａ，２Ｂ，２Ｃが暗号通信方式や共通鍵に
同意したことを検知する（ステップＳ１３８）。そし
て、クライアントサーバ２Ａ，２Ｂ，２ＣのＨａｎｄｓ
ｈａｋｅＰｒｏｔｏｃｏｌ部２２は、Ｈａｎｄｓｈａｋ
ｅＰｒｏｔｏｃｏｌの終了を表す”Ｆｉｎｉｓｈｅ
ｄ”メッセージを生成してＲｅｃｏｒｄＰｒｏｔｏｃ
ｏｌ部２１へ出力する。ＲｅｃｏｒｄＰｒｏｔｏｃｏ
ｌ部２１は、上記で決めた暗号化仕様に従って共通鍵Ｋ
Ｐａで”Ｆｉｎｉｓｈｅｄ”メッセージを暗号化し、
｛Ｆｉｎｉｓｈｅｄ｝ＫＰａをサーバ１へ出力する（ス
テップＳ１４０）。

【００６７】サーバ１のＲｅｃｏｒｄＰｒｏｔｏｃｏ
ｌ部１１は、ＣＡＰｒｏｘｙ４を介して｛Ｆｉｎｉｓ
ｈｅｄ｝ＫＰａを受信し、その受信した｛Ｆｉｎｉｓｈ
ｅｄ｝ＫＰａを共通鍵ＫＰａによって復号する。そし
て、ＲｅｃｏｒｄＰｒｏｔｏｃｏｌ部１１は、復号し
た”Ｆｉｎｉｓｈｅｄ”メッセージをＨａｎｄｓｈａｋ
ｅＰｒｏｔｏｃｏｌ部１２へ出力する。Ｈａｎｄｓｈ
ａｋｅＰｒｏｔｏｃｏｌ部１２は、”Ｆｉｎｉｓｈｅ
ｄ”メッセージを受理する（ステップＳ１４２）。

【００６８】最後に、図６に示すフローチャートについ
て説明する。その後、ＣｈａｎｇｅＣｉｐｈｅｒＳ
ｐｅｃＰｒｏｔｏｃｏｌ部１３は、”ＣｈａｎｇｅＣ
ｉｐｈｅｒＳｐｅｃ”メッセージを生成してＲｅｃｏｒ
ｄＰｒｏｔｏｃｏｌ部１１へ出力する。Ｒｅｃｏｒｄ
Ｐｒｏｔｏｃｏｌ部１１は、共通鍵ＫＰａによって”Ｃ
ｈａｎｇｅＣｉｐｈｅｒＳｐｅｃ”メッセージを暗号化
し、その暗号化した｛ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅ
ｃ｝ＫＰａをクライアントサーバ２Ａ，２Ｂ，２Ｃへ送
信する（ステップＳ１４４）。

【００６９】クライアントサーバ２Ａ，２Ｂ，２ＣのＲ
ｅｃｏｒｄＰｒｏｔｏｃｏｌ部２１は、ＣＡＰｒｏ
ｘｙ４を介して｛ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃ｝
ＫＰａを受信し、共通鍵ＫＰａによって｛Ｃｈａｎｇｅ
ＣｉｐｈｅｒＳｐｅｃ｝ＫＰａを復号する。そして、Ｒ
ｅｃｏｒｄＰｒｏｔｏｃｏｌ部２１は、復号した”Ｃ
ｈａｎｇｅＣｉｐｈｅｒＳｐｅｃ”メッセージをＣｈａ
ｎｇｅＣｉｐｈｅｒＳｐｅｃＰｒｏｔｏｃｏｌ部２
３へ出力する。ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃ
Ｐｒｏｔｏｃｏｌ部２３は、”ＣｈａｎｇｅＣｉｐｈｅ
ｒＳｐｅｃ”メッセージを受けてサーバ１が暗号通信方
式や共通鍵に同意したことを検知する（ステップＳ１４
６）。

【００７０】その後、ＨａｎｄｓｈａｋｅＰｒｏｔｏ
ｃｏｌ部１２は、クライアントサーバ２Ａ，２Ｂ，２Ｃ
へ送信するＨａｎｄｓｈａｋｅＰｒｏｔｏｃｏｌの終
了を示す”Ｆｉｎｉｓｈｅｄ”メッセージを生成してＲ
ｅｃｏｒｄＰｒｏｔｏｃｏｌ部１１へ出力する。Ｒｅ
ｃｏｒｄＰｒｏｔｏｃｏｌ部１１は、上記で決めた暗
号化仕様に従って共通鍵ＫＰａによって”Ｆｉｎｉｓｈ
ｅｄ”メッセージを暗号化し、｛Ｆｉｎｉｓｈｅｄ｝Ｋ
Ｐａをクライアントサーバ２Ａ，２Ｂ，２Ｃへ出力する
（ステップＳ１４８）。クライアントサーバ２Ａ，２
Ｂ，２ＣのＲｅｃｏｒｄＰｒｏｔｏｃｏｌ部２１は、
ＣＡＰｒｏｘｙ４を介して｛Ｆｉｎｉｓｈｅｄ｝ＫＰ
ａを受信し、その受信した｛Ｆｉｎｉｓｈｅｄ｝ＫＰａ
を共通鍵ＫＰａによって復号する。そして、Ｒｅｃｏｒ
ｄＰｒｏｔｏｃｏｌ部２１は、復号した”Ｆｉｎｉｓ
ｈｅｄ”メッセージをＨａｎｄｓｈａｋｅＰｒｏｔｏ
ｃｏｌ部２２へ出力する。ＨａｎｄｓｈａｋｅＰｒｏ
ｔｏｃｏｌ部２２は、”Ｆｉｎｉｓｈｅｄ”メッセージ
を受理する（ステップＳ１５０）。

【００７１】ステップＳ１５０まででサーバ１とクライ
アントサーバ２Ａ，２Ｂ，２ＣとのＨａｎｄｓｈａｋｅ
Ｐｒｏｔｏｃｏｌ、即ち、セッションの確立が終了す
る。そして、サーバ１のＡｐｐｌｉｃａｔｉｏｎＤａ
ｔａＰｒｏｔｏｃｏｌ部１５とアプリケーション部１
６、およびクライアントサーバ２Ａ，２Ｂ，２ＣのＡｐ
ｐｌｉｃａｔｉｏｎＤａｔａＰｒｏｔｏｃｏｌ部２
５とアプリケーション部２６による共通鍵ＫＰａを用い
た暗号通信が行なわれて（ステップＳ１５２）、サーバ
１とクライアントサーバ２Ａ，２Ｂ，２Ｃとの間の通信
が終了する（ステップＳ１５４）。

【００７２】図４から図６に示したフローチャートは、
クライアントサーバ２Ａ，２Ｂ，２Ｃが自己の電子証明
書を保持しない場合のサーバ１とクライアントサーバ２
Ａ，２Ｂ，２Ｃとのセッション確立時のフローチャート
である。上述したように、クライアントサーバ２Ａ，２
Ｂ，２Ｃが自己の電子証明書を保持しない場合でも、Ｃ
ＡＰｒｏｘｙ４は、クライアントサーバ２Ａ，２Ｂ，
２Ｃが正規のサーバであることを示すＣＡＰｒｏｘｙ
４の電子証明書をサーバ１へ代理応答し、サーバ１とク
ライアントサーバ２Ａ，２Ｂ，２Ｃとの間で相互認証が
行なわれる。

【００７３】図７〜図９は、サーバ１とクライアントサ
ーバ２Ａ，２Ｂ，２Ｃとのセッション確立時の別のフロ
ーチャートである。まず、図７に示すフローチャートに
ついて説明する。サーバ１とクライアントサーバ２Ａ，
２Ｂ，２Ｃとの間の通信が開始されると（ステップＳ２
００）、クライアントサーバ２Ａ，２Ｂ，２ＣのＨａｎ
ｄｓｈａｋｅＰｒｏｔｏｃｏｌ部２２は、”Ｃｌｉｅ
ｎｔＨｅｌｌｏ”メッセージをＲｅｃｏｒｄＰｒｏｔ
ｏｃｏｌ部２１を介して送信する（ステップＳ２０
２）。ＣＡＰｒｏｘｙ４の通信プロトコルキャプチャ
ー部４１は、クライアントサーバ２Ａ，２Ｂ，２Ｃから
の”ＣｌｉｅｎｔＨｅｌｌｏ”メッセージを受信し、そ
の受信した”ＣｌｉｅｎｔＨｅｌｌｏ”メッセージをサ
ーバ１へ送信する。サーバ１のＨａｎｄｓｈａｋｅＰ
ｒｏｔｏｃｏｌ部１２は、ＲｅｃｏｒｄＰｒｏｔｏｃ
ｏｌ部１１を介して”ＣｌｉｅｎｔＨｅｌｌｏ”メッセ
ージを受信する（ステップＳ２０４）。そして、Ｈａｎ
ｄｓｈａｋｅＰｒｏｔｏｃｏｌ部１２は、受信した”
ＣｌｉｅｎｔＨｅｌｌｏ”メッセージに含まれるプロト
コルバージョン、セッションＩＤ、および暗号アルゴリ
ズムの候補から１つのプロトコルバージョン、セッショ
ンＩＤ、および暗号アルゴリズムを選択し、その選択し
たプロトコルバージョン、セッションＩＤ、および暗号
アルゴリズムを”ＳｅｖｅｒＨｅｌｌｏ”メッセージに
含めてクライアントサーバ２Ａ，２Ｂ，２Ｃへ送信する
（ステップＳ２０６）。

【００７４】ＣＡＰｒｏｘｙ４の通信プロトコルキャ
プチャー部４１は、サーバ１からの”ＳｅｒｖｅｒＨｅ
ｌｌｏ”メッセージを受信し、その受信した”Ｓｅｒｖ
ｅｒＨｅｌｌｏ”メッセージをクライアントサーバ２
Ａ，２Ｂ，２Ｃへ送信する。クライアントサーバ２Ａ，
２Ｂ，２ＣのＨａｎｄｓｈａｋｅＰｒｏｔｏｃｏｌ部
２２は、”ＳｅｒｖｅｒＨｅｌｌｏ”メッセージをＲｅ
ｃｏｒＰｒｏｔｏｃｏｌ部２１を介して受信し、”Ｓ
ｅｒｖｅｒＨｅｌｌｏ”メッセージに基づいてサーバ１
が選択したプロトコルバージョン、セッションＩＤ、お
よび暗号アルゴリズムを確認する（ステップＳ２０
８）。これによって、サーバ１とクライアントサーバ２
Ａ，２Ｂ，２Ｃとの間の暗号通信方式が決定される。

【００７５】その後、サーバ１のＨａｎｄｓｈａｋｅ
Ｐｒｏｔｏｃｏｌ部１２は、電子証明書を保持するか否
かを判定し（ステップＳ２１０）、電子証明書を保持し
ていないと判定したとき、ステップＳ２２４へ移行す
る。ＨａｎｄｓｈａｋｅＰｒｏｔｏｃｏｌ部１２は、
電子証明書を保持していると判定したとき、”Ｓｅｒｖ
ｅｒＣｅｒｔｉｆｉｃａｔｅ”メッセージをＲｅｃｏｒ
ｄＰｒｏｔｏｃｏｌ部１１を介して送信する（ステッ
プＳ２１２）。ＣＡＰｒｏｘｙ４の通信プロトコルキ
ャプチャー部４１は、サーバ１からの”ＳｅｒｖｅｒＣ
ｅｒｔｉｆｉｃａｔｅ”を受信し、その受信した”Ｓｅ
ｒｖｅｒＣｅｒｔｉｆｉｃａｔｅ”メッセージをＣＲＬ
チェック部４２へ出力する。ＣＲＬチェック部４２
は、”ＳｅｒｖｅｒＣｅｒｔｉｆｉｃａｔｅ”メッセー
ジを受取り、サーバ１の電子証明書を証明書廃棄リスト
（ＣＲＬ）と照合し、サーバ１の電子証明書が証明書廃
棄リスト（ＣＲＬ）に含まれるか否かをチェックする。
そして、ＣＲＬチェック部４２は、照合結果を通信プロ
トコルキャプチャー部４１へ出力する（ステップＳ２１
４）。

【００７６】サーバ１の電子証明書が証明書廃棄リスト
（ＣＲＬ）に含まれる場合、通信プロトコルキャプチャ
ー部４１は、サーバ１の電子証明書が無効であることを
示す無効通知をサーバ１へ送信する（ステップＳ２１
６）。そして、サーバ１のＨａｎｄｓｈａｋｅＰｒｏ
ｔｏｃｏｌ部１２は、ＲｅｃｏｒｄＰｒｏｔｏｃｏｌ
部１１を介して無効通知を受信し（ステップＳ２１
８）、サーバ１とクライアントサーバ２Ａ，２Ｂ，２Ｃ
との通信は終了する（ステップＳ２７６）。つまり、サ
ーバ１は、正規のサーバではないと判断されたので、サ
ーバ１とクライアントサーバ２Ａ，２Ｂ，２Ｃとの通信
は終了し、クライアントサーバ２Ａ，２Ｂ，２Ｃの重要
な情報が不正なサーバへ漏洩するのを防止できる。

【００７７】ステップＳ２１４において、サーバ１の電
子証明書が証明書廃棄リスト（ＣＲＬ）に含まれていな
いと判断されたとき、ＣＡＰｒｏｘｙ４の通信プロト
コルキャプチャー部４１は、サーバ１から受信した電子
証明書をクライアントサーバ２Ａ，２Ｂ，２Ｃへ送信し
（ステップＳ２２０）、クライアントサーバ２Ａ，２
Ｂ，２ＣのＨａｎｄｓｈａｋｅＰｒｏｔｏｃｏｌ部２
２は、ＲｅｃｏｒｄＰｒｏｔｏｃｏｌ部２１を介して
サーバ１の電子証明書を受信する（ステップＳ２２
２）。これによって、サーバ１は正規のサーバであるこ
とが認証されるとともに、クライアントサーバ２Ａ，２
Ｂ，２Ｃは、サーバ１の公開鍵を取得する。

【００７８】一方、ステップＳ２１０においては、Ｈａ
ｎｄｓｈａｋｅＰｒｏｔｏｃｏｌ部１２が電子証明書
を保持していないと判定したとき、Ｈａｎｄｓｈａｋｅ
Ｐｒｏｔｏｃｏｌ部１２は、”ＳｅｒｖｅｒＫｅｙＥ
ｘｃｈａｎｇｅ”メッセージを生成してＲｅｃｏｒｄ
Ｐｒｏｔｏｃｏｌ部１１へ出力する。そして、Ｒｅｃｏ
ｒｄＰｒｏｔｏｃｏｌ部１１は、”ＳｅｒｖｅｒＫｅ
ｙＥｘｃｈａｎｇｅ”メッセージをクライアントサーバ
２Ａ，２Ｂ，２Ｃへ送信する（ステップＳ２２４）。こ
の”ＳｅｒｖｅｒＫｅｙＥｘｃｈａｎｇｅ”メッセージ
は、ＲＳＡ公開鍵またはＤｉｆｆｉｅ＆Ｈｅｌｌｍａｎ
公開情報から成る。サーバ１が電子証明書を保持しない
場合に、ＲＳＡ公開鍵またはＤｉｆｆｉｅ＆Ｈｅｌｌｍ
ａｎ公開情報をクライアントサーバ２Ａ，２Ｂ，２Ｃへ
送信することによってサーバ１が正規のサーバであるこ
とを電子証明書に代えて証明するものである。

【００７９】ステップＳ２２２またはステップＳ２２４
の後、サーバ１のＨａｎｄｓｈａｋｅＰｒｏｔｏｃｏ
ｌ部１２は、クライアントサーバ２Ａ，２Ｂ，２Ｃに対
して電子証明書の送信を要求するか否かを判定する（ス
テップＳ２２６）。電子証明書の送信を要求しないと
き、図９に示すステップＳ２５４へ移行する。また、Ｈ
ａｎｄｓｈａｋｅＰｒｏｔｏｃｏｌ部１２は、電子証
明書の提出を要求すると判定したとき、”Ｃｅｒｔｉｆ
ｉｃａｔｅＲｅｑｕｅｓｔ”をＲｅｃｏｒｄＰｒｏｔ
ｏｃｏｌ部１１を介して送信し、クライアントサーバ２
Ａ，２Ｂ，２ＣのＨａｎｄｓｈａｋｅＰｒｏｔｏｃｏ
ｌ部２２は、ＣＡＰｒｏｘｙ４およびＲｅｃｏｒｄ
Ｐｒｏｔｏｃｏｌ部２１を介して”Ｃｅｒｔｉｆｉｃａ
ｔｅＲｅｑｕｅｓｔ”を受信する。

【００８０】次に、図８に示すフローチャートについて
説明する。クライアントサーバ２Ａ，２Ｂ，２ＣのＨａ
ｎｄｓｈａｋｅＰｒｏｔｏｃｏｌ部２２は、電子証明
書を保持しているか否かを判定する（ステップＳ２２
８）。そして、ＨａｎｄｓｈａｋｅＰｒｏｔｏｃｏｌ
部２２は、電子証明書を保持していると判定したと
き、”ＣｌｉｅｎｔＣｅｒｔｉｆｉｃａｔｅ”メッセー
ジをＲｅｃｏｒｄＰｒｏｔｏｃｏｌ部２１を介してＣ
ＡＰｒｏｘｙ４へ送信する（ステップＳ２３０）。Ｃ
ＡＰｒｏｘｙ４の通信プロトコルキャプチャー部４１
は、クライアントサーバ２Ａ，２Ｂ，２Ｃから”Ｃｌｉ
ｅｎｔＣｅｒｔｉｆｉｃａｔｅ”メッセージを受信し、
その受信した”ＣｌｉｅｎｔＣｅｒｔｉｆｉｃａｔｅ”
メッセージを認証部４３および代理応答部４４へ出力す
る。そして、認証部４３は、”ＣｌｉｅｎｔＣｅｒｔｉ
ｆｉｃａｔｅ”メッセージを受取ると、そのメッセージ
に含まれている電子証明書に基づいてクライアントサー
バ２Ａ，２Ｂ，２Ｃを正規のサーバとして認証し、保持
しているＣＡＰｒｏｘｙ４の電子証明書を代理応答部
４４へ出力する（ステップＳ２３２）。

【００８１】ステップＳ２２８において、Ｈａｎｄｓｈ
ａｋｅＰｒｏｔｏｃｏｌ部２２が電子証明書を保持し
ていないと判定したとき、ＨａｎｄｓｈａｋｅＰｒｏ
ｔｏｃｏｌ部２２は、”ＮｏＣｅｒｔｉｆｉｃａｔｅ”
メッセージをＣＡＰｒｏｘｙ４へ送信する（ステップ
Ｓ２３４）。そして、ＣＡＰｒｏｘｙ４の通信プロト
コルキャプチャー部４１は、クライアントサーバ２Ａ，
２Ｂ，２Ｃから”ＮｏＣｅｒｔｉｆｉｃａｔｅ”メッセ
ージを受信し、その受信した”ＮｏＣｅｒｔｉｆｉｃ
ａｔｅ”メッセージを認証部４３および代理応答部４４
へ出力する。認証部４３は、”ＮｏＣｅｒｔｉｆｉｃ
ａｔｅ”メッセージを受取ると、保持しているＣＡＰ
ｒｏｘｙ４の電子証明書を代理応答部４４へ出力する
（ステップＳ２３６）。

【００８２】ステップＳ２３２またはステップＳ２３６
の後、代理応答部４４は、通信プロトコルキャプチャー
部４１からの”ＣｌｉｅｎｔＣｅｒｙｉｆｉｃａｔｅ”
メッセージまたは”ＮｏＣｅｒｔｉｆｉｃａｔｅ”メ
ッセージを受けると、サーバ１に対して代理応答するか
否かを判定する（ステップＳ２３８）。代理応答部４４
が代理応答しないと判定したとき、ステップＳ２７６へ
移行し、通信は終了する。代理応答部４４は、代理応答
すると判定すると、認証部４３から入力されたＣＡＰ
ｒｐｘｙ４の電子証明書を通信プロトコルキャプチャー
部４１を介してサーバ１へ送信する（ステップＳ２４
０）。

【００８３】サーバ１のＨａｎｄｓｈａｋｅＰｒｏｔ
ｏｃｏｌ部１２は、ＲｅｃｏｒｄＰｒｏｔｏｃｏｌ部１
１を介してＣＡＰｒｏｘｙ４からの電子証明書を受信
し、その受信した電子証明書に基づいてＣＡＰｒｏｘ
ｙ４が正規のサーバであることを認証するとともに、ク
ライアントサーバ２Ａ，２Ｂ，２Ｃとの暗号通信に用い
る公開鍵を取得する（ステップＳ２４２）。この場合、
ＨａｎｄｓｈａｋｅＰｒｏｔｏｃｏｌ部１２は、上述し
たように、クライアントサーバ２Ａ，２Ｂ，２Ｃを正規
のサーバとして認証する。

【００８４】その後、クライアントサーバ２Ａ，２Ｂ，
２ＣのＨａｎｄｓｈａｋｅＰｒｏｔｏｃｏｌ部２２
は、４８バイトの乱数を発生させ、その発生させた乱数
をＲｅｃｏｒｄＰｒｏｔｏｃｏｌ部２１へ出力する。
ＲｅｃｏｒｄＰｒｏｔｏｃｏｌ部２１は、入力された
乱数を公開鍵Ｐａで暗号化し、その暗号化した乱数を”
ＣｌｉｅｎｔＫｅｙＥｘｃｈａｎｇｅ”メッセージとし
てサーバ１へ送信する（ステップＳ２４４）。また、Ｈ
ａｎｄｓｈａｋｅＰｒｏｔｏｃｏｌ部２２は、発生し
た乱数を用いてサーバ１とクライアントサーバ２Ａ，２
Ｂ，２Ｃとの間でデータを暗号通信する際の共通鍵を生
成する。

【００８５】一方、サーバ１のＲｅｃｏｒｄＰｒｏｔ
ｏｃｏｌ部１１は、ＣＡＰｒｏｃｙ４を介して”Ｃｌ
ｉｅｎｔＫｅｙＥｘｃｈａｎｇｅ”メッセージを受信
し、暗号化された乱数を秘密鍵Ｓａで復号する（ステッ
プＳ２４６）。そして、ＲｅｃｏｒｄＰｒｏｔｏｃｏ
ｌ部１１は、復号した乱数をＨａｎｄｓｈａｋｅＰｒ
ｏｔｏｃｏｌ部１２へ出力する。Ｈａｎｄｓｈａｋｅ
Ｐｒｏｔｏｃｏｌ部１２は、入力された４８バイトの乱
数を用いて共通鍵を生成する。

【００８６】クライアントサーバ２Ａ，２Ｂ，２ＣのＨ
ａｎｄｓｈａｋｅＰｒｏｔｏｃｏｌ部２２は、再度、
電子証明書を保持するか否かを判定する（ステップＳ２
４８）。電子証明書が保持されているときステップＳ２
５０へ移行し、保持されていないときステップＳ２５８
へ移行する。

【００８７】最後に、図９に示すフローチャートについ
て説明する。ステップＳ２４８において、電子証明書が
保持されていると判定されたとき、Ｈａｎｄｓｈａｋｅ
Ｐｒｏｔｏｃｏｌ部２２は、サーバ１がクライアント
サーバ２Ａ，２Ｂ，２Ｃの電子証明書が正しいことを確
認するために、ステップＳ２４８までに取得されメッセ
ージのダイジェストをＲｅｃｏｒｄＰｒｏｔｏｃｏｌ
部２１へ出力する。ＲｅｃｏｒｄＰｒｏｔｏｃｏｌ部
２１は、入力されたメッセージのダイジェストを秘密鍵
Ｓａで暗号化し、”ＣｅｒｔｉｆｉｃａｔｅＶｅｒｉｆ
ｙ”としてサーバ１へ送信する（ステップＳ２５０）。
サーバ１のＲｅｃｏｒｄＰｒｏｔｃｏｌ部１１は、”
ＣｅｒｔｉｆｉｃａｔｅＶｅｒｉｆｙ”をＣＡＰｒｏ
ｘｙ４を介して受信し、暗号化されたメッセージのダイ
ジェストを公開鍵で復号する。そして、Ｒｅｃｏｒｄ
Ｐｒｏｔｏｃｏｌ部１１は、復号したメッセージのダイ
ジェストをＨａｎｄｓｈａｋｅＰｒｏｔｏｃｏｌ部１
２へ出力し、ＨａｎｄｓｈａｋｅＰｒｏｔｏｃｏｌ部
１２は、入力されたメッセージのダイジェストに基づい
てクライアントサーバ２Ａ，２Ｂ，２Ｃの電子証明書が
正しいを確認する（ステップＳ２５２）。

【００８８】一方、ステップＳ２２６（図７参照）にお
いて、サーバ１がクライアントサーバ２Ａ，２Ｂ，２Ｃ
の電子証明書の送信を要求しないと判定としたとき、ク
ライアントサーバ２Ａ，２Ｂ，２ＣのＨａｎｄｓｈａｋ
ｅＰｒｏｔｏｃｏｌ部２２は、４８バイトの乱数を発
生させ、その発生させた乱数をＲｅｃｏｒｄＰｒｏｔ
ｏｃｏｌ部２１へ出力する。ＲｅｃｏｒｄＰｒｏｔｏ
ｃｏｌ部２１は、入力された乱数をサーバ１の公開鍵Ｐ
ａで暗号化し、その暗号化した乱数を”ＣｌｉｅｎｔＫ
ｅｙＥｘｃｈａｎｇｅ”メッセージとしてサーバ１へ送
信する（ステップＳ２５４）。また、Ｈａｎｄｓｈａｋ
ｅＰｒｏｔｏｃｏｌ部２２は、発生した乱数を用いて
サーバ１とクライアントサーバ２Ａ，２Ｂ，２Ｃとの間
でデータを暗号通信する際の共通鍵を生成する。

【００８９】一方、サーバ１のＲｅｃｏｒｄＰｒｏｔ
ｏｃｏｌ部１１は、ＣＡＰｒｏｃｙ４を介して”Ｃｌ
ｉｅｎｔＫｅｙＥｘｃｈａｎｇｅ”メッセージを受信し
（、暗号化された乱数を秘密鍵Ｓａで復号する（ステッ
プＳ２５６）。そして、ＲｅｃｏｒｄＰｒｏｔｏｃｏ
ｌ部１１は、復号した乱数をＨａｎｄｓｈａｋｅＰｒ
ｏｔｏｃｏｌ部１２へ出力する。Ｈａｎｄｓｈａｋｅ
Ｐｒｏｔｏｃｏｌ部１２は、入力された４８バイトの乱
数を用いて共通鍵を生成する。

【００９０】ステップＳ２４８においてクライアントサ
ーバ２Ａ，２Ｂ，２Ｃで電子証明書が保持されていない
と判定されたとき、またはステップＳ２５２，Ｓ２５６
の後、クライアントサーバ２Ａ，２Ｂ，２ＣのＣｈａｎ
ｇｅＣｉｐｈｅｒＳｐｅｃＰｒｏｔｏｃｏｌ部２
３は、ステップＳ２５６までにサーバ１とクライアント
２Ａ，２Ｂ，２Ｃとの間で合意された暗号通信方式に同
意し、生成した共通鍵を認めることを示す”Ｃｈａｎｇ
ｅＣｉｐｈｅｒＳｐｅｃ”メッセージを生成してＲｅｃ
ｏｒｄＰｒｏｔｏｃｏｌ部２１へ出力する。Ｒｅｃｏ
ｒｄＰｒｏｔｏｃｏｌ部２１は、共通鍵ＫＰａによっ
て”ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃ”メッセージを
暗号化した｛ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃ｝ＫＰ
ａを生成してクライアントサーバ２Ａ，２Ｂ，２Ｃへ送
信する（ステップＳ２５８）。

【００９１】それ以後のステップＳ２６０〜Ｓ２７６
は、図５および図６のステップＳ１３８〜１５４と同じ
である。

【００９２】図７〜図９に示すフローチャートは、サー
バ１が電子証明書を保持しない場合に、ＲＳＡ公開鍵ま
たはＤｉｆｆｉｅ＆Ｈｅｌｌｍａｎ公開情報をクライア
ントサーバ２Ａ，２Ｂ，２Ｃへ送信してサーバ１の正当
性を認証してもらう点が、図４〜図６に示したフローチ
ャートと特に異なる点である。

【００９３】上記においては、サーバとクライアントサ
ーバとの間の暗号通信方式をＳＳＬ暗号通信として説明
したが、本発明は、これに限られるものではなく、公開
鍵暗号方式であれば、どのような暗号方式を用いたもの
であっても良い。

【００９４】この発明の実施の形態によれば、暗号通信
システムは、サーバに対してクライアントサーバが正規
のサーバであることを代理応答するＣＡＰｒｏｘｙを
備えるので、クライアントの個人情報がサーバに公開さ
れることなく、サーバとクライアントサーバとの間で相
互に認証し、暗号通信を行なうことができる。

【００９５】今回開示された実施の形態はすべての点で
例示であって制限的なものではないと考えられるべきで
ある。本発明の範囲は上記した説明ではなくて特許請求
の範囲によって示され、特許請求の範囲と均等の意味お
よび範囲内でのすべての変更が含まれることが意図され
る。

【００９６】

【発明の効果】この発明による暗号通信システムは、サ
ーバに対してクライアントサーバが正規のサーバである
ことを自己の電子証明書を用いて代理応答するＣＡＰ
ｒｏｘｙを備えるので、クライアントの個人情報がサー
バに公開されることなく、サーバとクライアントサーバ
との間で相互に認証し、暗号通信を行なうことができ
る。

【図面の簡単な説明】

【図１】本発明の実施の形態による暗号通信システム
の概略ブロック図である。

【図２】図１に示すサーバ、クライアントサーバ、お
よびＣＡＰｒｏｘｙの機能ブロック図である。。

【図３】電子証明書の構成を示す概略ブロック図であ
る。

【図４】サーバとクライアントサーバとの間のセッシ
ョン確立時の第１のフローチャートである。

【図５】サーバとクライアントサーバとの間のセッシ
ョン確立時の第２のフローチャートである。

【図６】サーバとクライアントサーバとの間のセッシ
ョン確立時の第３のフローチャートである。

【図７】サーバとクライアントサーバとの間の他の方
法によるセッション確立時の第１のフローチャートであ
る。

【図８】サーバとクライアントサーバとの間の他の方
法によるセッション確立時の第２のフローチャートであ
る。

【図９】サーバとクライアントサーバとの間の他の方
法によるセッション確立時の第３のフローチャートであ
る。

【図１０】ＯＳＩ参照モデルを用いたコンピュータ間
の通信するための概略図である。

【図１１】ＯＳＩ参照モデルの各層の機能を説明する
ための図表である。

【図１２】従来のＳＳＬ代理応答システムの概略ブロ
ック図である。

【符号の説明】

１，２４０サーバ、２Ａ，２Ｂ，２Ｃクライアント
サーバ、３インターネット網、４ＣＡＰｒｏｘ
ｙ、５結合器、１０暗号通信システム、１１，２１
ＲｅｃｏｒｄＰｒｏｔｏｃｏｌ部、１２，２２Ｈ
ａｎｄｓｈａｋｅＰｒｏｔｏｃｏｌ部、１３，２３Ｃ
ｈａｎｇｅＣｉｐｈｅｒＳｐｅｃＰｒｏｔｏｃｏｌ
部、１４，２４ＡｌｅｒｔＰｒｏｔｏｃｏｌ部、１
５，２５ＡｐｐｌｉｃａｔｉｏｎＤａｔａＰｒｏ
ｔｏｃｏｌ部、１６，２６アプリケーション部、４１
通信プロトコルキャプチャー部、４２ＣＲＬチェッ
ク部、４３認証部、４４代理応答部、５０電子証
明書、５１バージョン、５２シリアル番号、５３
証明書発行者、５４発行者ユニーク識別子、５５証
明対象ユーザ、５６ユーザユニーク識別子、５７証
明対象公開鍵アルゴリズム、５８証明対象公開鍵、５
９証明書有効期限、６０証明書拡張、６１署名ア
ルゴリズム、６２署名、２００ＳＳＬ代理応答シス
テム、２１０インターネット、２２０ファイアウォ
ール、２３０代理サーバ。

─────────────────────────────────────────────────────

【手続補正書】

【提出日】平成１３年２月２７日（２００１．２．２
７）

【手続補正１】

【補正対象書類名】図面

【補正対象項目名】図５

【補正方法】変更

【補正内容】

【図５】

【手続補正２】

【補正対象書類名】図面

【補正対象項目名】図８

【補正方法】変更

【補正内容】

【図８】

【手続補正３】

【補正対象書類名】図面

【補正対象項目名】図９

【補正方法】変更

【補正内容】

【図９】

───────────────────────────────────────────────────── フロントページの続き (72)発明者山崎達也京都府相楽郡精華町光台二丁目２番地２株式会社エイ・ティ・アール環境適応通信研究所内Ｆターム(参考） 5J104 AA01 AA07 EA05 JA21 KA02 MA01 NA02 PA07

Claims

【特許請求の範囲】

【請求項１】複数の層構造から成るプロトコルを用い
て、所定の暗号方式によって暗号化された暗号データの
通信を行なう暗号通信システムであって、データまたは前記暗号データを送受信する第１のサーバ
と、前記第１のサーバとの間で前記データまたは暗号データ
を送受信する第２のサーバと、前記第１のサーバと前記第２のサーバとの通信を中継す
る第３のサーバとを備え、前記第２のサーバの認証時、前記第３のサーバは、前記
第１のサーバからの前記第２のサーバの証明書の要求に
応じて、前記第２のサーバが正規のサーバであることを
示す代理証明書を前記第２のサーバに代わって前記第１
のサーバへ送信する、暗号通信システム。
【請求項２】前記第３のサーバは、自己の証明書を前
記代理証明書として前記第１のサーバへ送信する、請求
項１に記載の暗号通信システム。
【請求項３】前記第３のサーバは、前記第２のサーバ
の証明書の要求を前記第２のサーバへ送信し、前記第２
のサーバから前記第２のサーバの証明書を受信すると前
記代理証明書を前記第１のサーバへ送信する、請求項１
または請求項２に記載の暗号通信システム。
【請求項４】前記第３のサーバは、前記第２のサーバ
の証明書の要求を前記第２のサーバへ送信し、前記第２
のサーバが証明書を保持しないことを示す情報を前記第
２のサーバから受信すると前記代理証明書を前記第１の
サーバへ送信する、請求項１または請求項２に記載の暗
号通信システム。
【請求項５】前記第３のサーバは、前記第１のサーバ
から受信した前記第１のサーバの証明書を証明書廃棄リ
ストと照合し、前記第１のサーバの証明書が廃棄されて
いるとき前記第１のサーバの証明書が無効であることを
示す情報を前記第１のサーバへ送信する、請求項１から
請求項４のいずれか１項に記載の暗号通信システム。
【請求項６】前記第３のサーバは、前記第１のサーバ
から受信した前記第１のサーバの証明書を証明書廃棄リ
ストと照合し、前記第１のサーバの証明書が廃棄されて
いないことを確認すると前記代理証明書を前記第１のサ
ーバへ送信する、請求項１から請求項４のいずれか１項
に記載の暗号通信システム。
【請求項７】前記第３のサーバは、前記第１のサーバと前記第２のサーバとの間の通信を制
御する通信制御部と、前記通信制御部を介して受取った前記第１のサーバの証
明書を前記証明書廃棄リストと照合する証明書照合部
と、前記証明書照合部からの照合結果に基づいて、前記第１
のサーバを認証し、または前記第１のサーバの証明書を
無効と判定する認証部と、前記通信制御部を介して前記第２のサーバの証明書また
は前記第２のサーバが証明書を保持しない情報を受取る
と、前記代理証明書を前記第１のサーバへ送信する代理
応答部とを含む、請求項５または請求項６に記載の暗号
通信システム。
【請求項８】第１のサーバと第２のサーバとの間にお
ける認証方法であって、前記第２のサーバの証明書の送信要求を前記第１のサー
バから受信する第１のステップと、前記第２のサーバの証明書に代えて代理証明書を前記第
１のサーバへ送信する第２のステップとを備える認証方
法。
【請求項９】前記第２のステップにおいて、前記代理
証明書は、前記第２のサーバが証明書を保持するか否か
に拘わらず前記第１のサーバへ送信される、請求項８に
記載の認証方法。