JP2005217679A - 通信相手の認証を行う認証サーバ - Google Patents

Abstract

【課題】
通信先端末が、セキュア通信の要求を通信元端末から受けた場合に、当該通信要求を受け付けてよいか判定することや、通信元端末が正しいかどうか認証することができない。また、通信元端末が通信先端末へセキュア通信を行おうとする場合に、通信元端末は、接続相手である通信先端末が正しい接続相手であるかどうか判定することができない。
【解決手段】
通信元端末が所属するサイトに認証サーバを置き、通信元端末は、通信元端末が所属するサイトの認証サーバにアクセス可否を問い合わせる。また、通信先端末が所属するサイトに認証サーバを置き、通信先端末は、通信先端末が所属するサイトの認証サーバにアクセス可否を問い合わせる。
【選択図】図１

Description

本発明は、通信時にアクセス制御を行うサーバに関し、特に、公開鍵証明書と、接続ポリシーを利用して通信可否を判断するサーバに関する。

ネットワークを通じたセキュア通信は、データを暗号化して送受信することにより実現される。セキュア通信は、以下の手順で実現される。

まず、セキュア通信を行う端末は、通信相手が意図した相手であることを確認するために、通信相手を認証する。通信相手の認証に成功すると、暗号鍵の共有を行い、共有した鍵を用いて、お互いの通信データの暗号化を行う。

セキュア通信において通信相手の認証を行うために、電子署名を用いる方法がある。電子署名では、公開鍵と秘密鍵のペアを用いる公開鍵暗号技術が利用されている。

電子署名について簡単に説明すると以下のようである。

署名者は署名者のＩＤに対して署名者の秘密鍵で電子署名を生成する。次に、署名者のＩＤに電子署名を付与して検証者に送る。一方、検証者は、署名者から送られてきた電子署名を当該署名者の公開鍵によって検証することにより、受け取ったＩＤが改ざんされることなく、署名者から送られてきたことが確認でき、署名者を認証することができる。

上記公開鍵が署名者のものであることを証明するために、公開鍵証明書が用いられることが多い。公開鍵証明書には上記公開鍵や当該公開鍵の所有者などの情報が含まれており、認証局と呼ばれる証明書発行機関において電子署名が付与されたものである。

公開鍵証明書には、有効期限が定められている。また、有効期限内であっても様々な理由により失効することがある。このため、公開鍵が確かに署名者のものであることを確認するためには、検証者が署名者の公開鍵証明書が有効であることを検証することが必要である。

公開鍵証明書を検証するには、公開鍵証明書に付与されている認証局の署名が正しいことや、公開鍵証明書が有効期限内であること、公開鍵証明書が失効していないことを確認する必要がある。

ネットワークを通じたセキュア通信を行う場合には、通信元端末と通信先端末とが、一方が署名者の場合は他方が検証者となり、それぞれ署名者と検証者の立場を替えて、お互いに通信相手の認証を行う。

また、ネットワークを通じたセキュア通信では、あらかじめアクセスを許す相手を定めた接続ポリシーを決めておくことで、セキュア通信を許可する端末を制限するといった、アクセス制御を行う方法が用いられることがある。端末で、電子署名を用いた相手認証とアクセス制御を同時に行えば、あらかじめ定めておいた相手とのみセキュア通信ができる。

ただし、端末で電子署名を用いた相手認証を行うには、通信相手の公開鍵証明書の検証が必要であり、端末にとって処理負荷が大きい、という課題がある。また、端末がアクセス制御を行うためには、端末ごと接続ポリシーを設定することになり、接続ポリシーの集中管理ができない、という課題がある。これらの課題を解決するために、公開鍵証明書の検証とアクセス制御の機能をサーバで行う方法が提案されている(例えば特許文献１など)。

特許文献１では、企業外のネットワークに接続しているクライアントから、企業ネットワークシステムの業務サーバにアクセスする際に、公開鍵証明書を用いて認証を行う。

特開２０００−１０９３０号公報

特許文献１の手法は、ネットワークを通じたセキュア通信に適用することができる。あるサイトに所属する通信元端末のユーザが、別のサイトに所属する通信先端末とセキュア通信を行うとする。通信元端末のユーザは、通信元端末を介して、通信先端末とセキュア通信を行うために、以下のステップを行う。

通信元端末は、通信先端末が所属するサイトのアクセス制御サーバに、ユーザの通信先端末へのアクセス可否の判定要求を送る。アクセス制御サーバは、アクセス可否を判定し、判定結果を通信元端末に返す。ユーザの通信先端末へのアクセス判定が、可であれば、ユーザは、通信元端末から通信先端末へアクセスする。一方、ユーザの通信先端末へのアクセス判定が否であれば、通信元端末は通信先端末へのアクセスを行わない。

上記特許文献１で提案されている技術をセキュア通信に適用した場合、通信元端末がアクセス制御サーバの判定に基づいて通信先端末にアクセスするか否かを決定する。しかし、通信先端末が、セキュア通信の要求を通信元端末から受けた場合に、当該通信要求を受け付けてよいか判定することや、通信元端末が正しいかどうか認証することについては、特許文献１では言及していない。

また、通信元端末を利用するユーザが正しいかどうか認証する手段についても、特許文献１では言及していない。

さらに、通信元端末が通信先端末へセキュア通信を行おうとする場合に、通信元端末またはそのユーザが、接続相手である通信先端末が正しい接続相手であるかどうか判定することについても、特許文献１では言及していない。

さらに、あるサイト内の通信元端末から別のサイトのアクセス制御サーバへ通信許可を求めるためには、通信元端末が所属するサイトと、アクセス制御サーバが所属するサイトとの間で、アクセス可否の問い合わせを行わなければならないが、特許文献１ではこの点について言及していない。

本発明は、通信元端末が所属するサイトと、通信先端末が所属するサイトとにそれぞれ認証サーバ装置（以下、認証サーバという）を置き、通信元端末と通信先端末は、それぞれが所属するサイトの認証サーバに通信可否、すなわち、アクセスまたはその受け付けの可否、を問い合わせる通信システムを提供する。

本発明におけるサイトとは、たとえば、企業や企業の部署等の組織単位のサブネットワーク、あるいは、特定のインターネットサービスプロバイダの会員の端末と当該プロバイダの回線からなるサブネットワーク、のような、特定のグループに所属するユーザのみが接続できるサブネットワークにおける端末やサーバを含むシステム全体を指す。また、特定のアドレス範囲で示される組織に所属する、端末やサーバを含むシステム全体を指す場合もある。

上記通信システムは、具体的には、通信先端末が、通信元端末あるいは通信元端末を利用するユーザから、通信の要求を受けた場合には、当該通信要求を受け付けてよいかどうかを、通信先端末が所属するサイトの認証サーバに、通信元端末あるいは通信元端末を利用するユーザの公開鍵証明書と、通信先端末の公開鍵証明書、を添付して問い合わせることを特徴とする。

上記認証サーバは、接続の可否を判定するために予め定められた接続ポリシーを保持しており、通信要求が当該接続ポリシーに適合しているかどうか判定する。次に、上記認証サーバは、通信要求に添付された公開鍵証明書の有効性を検証する。上記認証サーバは、当該接続ポリシーに適合し、公開鍵証明書の検証に成功した場合に、通信許可通知を通信先端末に返答する。

上記通信システムは、一方、通信元端末あるいは通信元端末を利用するユーザが、通信の要求を出そうとする場合には、当該通信要求を行ってよいかどうかを、通信元端末が所属するサイトの認証サーバに、通信元端末あるいは通信元端末を利用するユーザの公開鍵証明書、と通信先端末の公開鍵証明書、を添付して問い合わせることを特徴とする。

上記認証サーバは、通信要求を行ってよいかどうかを判定するために予め定められた接続ポリシーを保持しており、通信要求が当該接続ポリシーに適合しているかどうか判定する。次に、上記認証サーバは、通信要求に添付された公開鍵証明書の有効性を検証する。上記認証サーバは、当該接続ポリシーに適合し、公開鍵証明書の検証に成功した場合には、通信許可通知を通信元端末に返答する。

上記構成により、通信先端末が、通信の要求を通信元端末から受けた場合に、当該通信要求を受け付けてよいか判定することができ、また、通信元端末が正しいかどうか認証することができる。

また、通信元端末を利用するユーザが正しいかどうか認証することができる。

さらに、通信元端末が通信先端末へ通信を行おうとする場合に、通信元端末は、接続相手である通信先端末が正しい接続相手であるかどうか判定することができる。

また、通信元端末を利用するユーザが接続相手である通信先端末が正しい接続相手であるかどうか判定することができる。

なお、通信元端末とアクセス制御サーバ間の通信は、サイト内で行われるために、サイト管理者のアクセス制御サーバへの通信許可なしに、通信元端末とアクセス制御サーバの間は通信することができる。

本発明によれば、複数の通信端末は、互いに正しい相手通信端末との、安全な通信を行うことが可能になる。

以下、本発明の実施の形態を詳細に説明する。なお、これによって本発明が限定されるものではない。

図１は、本発明の実施の一形態に係わるセキュア通信システムの構成を示すブロック図である。

図１のセキュア通信システムは、サイトＡ内のネットワーク４１に端末２_１、端末２_３、端末２_４、端末２_５、認証サーバ３_１、が接続しており、サイトＢ内のネットワーク４２に端末２_２、端末２_６、端末２_７、端末２_８、認証サーバ３_２、が接続している。サイトＡ内のネットワーク４１は、サイト外のネットワーク４０を介して、サイトＢ内のネットワーク４２に接続している。なお、以下、端末２_１、端末２_２、…、端末２_８を総称して、端末２とも記述する。また、認証サーバ３_１と認証サーバ３_２とを総称して、認証サーバ３、とも記述する。

また、端末２_１、端末２_２、…、端末２_８は、認証局からそれぞれ発行された公開鍵証明書５０９_１、５０９_２、…、５０９_８を端末内に保管している。さらに、それぞれ、認証サーバに通信可否を問い合わせるための、認証サーバ問い合わせ機能２０３_１、２０３_２、…、２０３_８と、暗号化通信に用いる鍵を共有するための、鍵共有機能２０２_１、２０２_２、…、２０２_８と、他の端末とネットワークを介して通信するための、通信機能２０１_１、２０１_２、…、２０１_８を備えている。

また、認証サーバ３_１、３_２は、接続可否の情報を記載した接続ポリシー３０_１、３０_２と、それぞれ公開鍵証明書の有効性を検証するための、証明書検証機能３０１_１、３０１_２と、通信可否の問い合わせが接続ポリシー３０_１、３０_２に合致しているか判定するための、アクセス制御機能３０２_１、３０２_２と、接続ポリシー３０_１、３０_２の作成や変更を行うための、接続ポリシー管理機能３０３_１、３０３_２、を備えている。なお、接続ポリシー３０_１、接続ポリシー３０_２を総称して、接続ポリシー３０とも記述する。

図６は、認証サーバ３_１が備えている接続ポリシー３０_１の一例である。

図６に示すように、認証サーバ３が保持する接続ポリシー３０は、デフォルトの接続ポリシー３１０と、それに優先する設定する接続ポリシー（許可）３１２からなる。デフォルトの接続ポリシー３１０は、通信元の端末２と、通信先の端末２と、通信を許可する期間と、を指定するものであり、具体的な内容は、全ての端末２から全ての端末２へのセキュア通信を無期限に拒否する、というものである。

接続ポリシー（許可）３１２は、複数のエントリから構成されており、一つのエントリは通信元の端末２と、通信先の端末２と、通信を許可する期間と、を指定する。接続ポリシー３１３は、設定する接続ポリシー（許可）３１２の一つのエントリである。接続ポリシー３１３では、端末２_１と端末２_２との接続を、２００２年１月１日から２００４年１２月３１日まで許可する、という接続ポリシー３０が記載されている。

なお、設定する接続ポリシー（許可）３１２は、接続ポリシー管理機能３０３_１で編集することができる。

一方、接続ポリシー３０_１として図６に示す接続ポリシー３０の代わりに図７に示すような、接続を拒否する端末２を指定する接続ポリシー３０を用いることもできる。図７における認証サーバ３が保持する接続ポリシー３０は、デフォルトの接続ポリシー３２０と、それに優先する設定する接続ポリシー３２２からなる。

図７におけるデフォルトの接続ポリシー３２０は、通信元の端末２と、通信先の端末２と、通信を許可する期間と、を指定するものであり、具体的な内容は、全ての端末２から全ての端末２へのセキュア通信を無期限に許可する、というものである。

図７における設定する接続ポリシー（拒否）３２２は、複数のエントリから構成されており、一つのエントリは通信元の端末２と、通信先の端末２と、通信を拒否する期間と、を指定する。接続ポリシー３２３は、設定する接続ポリシー（許可）３１２の一つのエントリである。接続ポリシー３２３では、端末２_１と端末２_２との接続を、２００２年１月１日から２００４年１２月３１日まで拒否する、という接続ポリシー３０が記載されている。

なお、設定する接続ポリシー（拒否）３２２は、接続ポリシー管理機能３０３_１で編集することができる。

なお、上記説明では、認証サーバ３_１の接続ポリシー３０_１について説明したが、認証サーバ３_２においても同様の形式で、接続ポリシー３０_２を指定する。

なお、本実施例では、設定する接続ポリシー３１３あるいは、接続ポリシー３２３、で端末２_１から端末２_２へのセキュア通信に関する接続ポリシー３０を設定しているが、本発明はそれに限定されるものではない。例えば、通信元、あるいは通信先として、複数の端末２を一つのグループとして設定することができる。

図８の表３３０に示すように、端末２_１から端末２_２へのセキュア通信３３１、端末２_１から端末２_２と端末２_６のグループへのセキュア通信３３２、端末２_１と端末２_３のグループから端末２_２へのセキュア通信３３３、端末２_１と端末２_３のグループから端末２_２と端末２_６のグループへのセキュア通信３３４、に対して接続ポリシー３０を設定することもできる。

上述のグループとは、端末の集合のことであり、接続ポリシー３０で用いるグループとは、サイト全体、サイトに所属する各々の企業、企業内組織、（例えば、部、課、プロジェクトグループ）などのようなグループが考えられる。

このように、端末と端末の間のセキュア通信に限らず、端末と端末グループ間、端末グループと端末グループ間のセキュア通信においても、本実施例を適用することができる。

さらに、認証サーバ３の接続ポリシー３０を端末のサービス単位に設定することもできる。例えば、端末２_１が図９に示すサービス１（３４１）、サービス２（３４２）、…を提供しており、それぞれのサービスには、サービスＩＤが割り当てられているとする。このとき、認証サーバ３_１は図１０に示す接続ポリシー３０を設定すればよい。

具体的には、デフォルトの接続ポリシー３５０は、通信元端末２と、通信先端末２と、期間と、期間内にサービスを許可するのか拒否するのかと、を指定する。例えば、エントリ３５１では、端末２_１のサービスＩＤ１へのアクセスは、無期限に拒否することを示している。

デフォルトの接続ポリシー３５０に優先する接続ポリシー３５４は、通信元端末２と、通信先端末２と、期間と、期間内にサービスを許可するのか拒否するのかと、を指定する。例えば、エントリ３５５では、端末２_２から端末２_１のサービスＩＤ１へのアクセスを２００２年１月１日から２００２年１月３１日まで許可することを示している。さらに、エントリ３５６では、端末２_６から端末２_１のサービスＩＤ１へのアクセスを２００２年１月１日午前０時から午後１１時５９分まで許可する。

したがって、接続ポリシー３５０により、端末２_１のサービスＩＤ１に対しては、デフォルトで無期限に接続を拒否するが、それに優先する接続ポリシー３５４のエントリ３５５に指定した期間に限り、端末２_２からの接続を許可し、エントリ３５６に指定した期間に限り、端末２_６からの接続を許可する。

また、デフォルトの接続ポリシー３５０のエントリ３５２では、端末２_１のサービスＩＤ１へのアクセスは、デフォルトで、無期限に許可する。デフォルトの接続ポリシー３５０に優先する接続ポリシー３５４のエントリ３５７では、端末２_２から端末２_１のサービスＩＤ１へのアクセスを毎日、午後１１時から、翌日午前６時まで拒否することを示している。さらに、エントリ３５８では、端末２_６から端末２_１のサービスＩＤ１へのアクセスを２００２年１月１日から２００２年１２月３１日まで拒否する。

このように、端末がサービスを提供している場合に、サービスを利用する端末が、サービスを提供する端末にアクセスする際に、本発明を適用可能である。

なお、図１に示す端末２_１、から端末２_８、認証サーバ３_１、３_２の各装置と、これら装置が備える各機能は、例えば、図１６に示すような、ＣＰＵ６１と、メモリ６２と、ハードディスク等の外部記憶装置６３と、ネットワークやＬＡＮ６９を介して他装置と通信を行うための通信装置６４と、キーボードやマウス等の入力装置６５と、モニタやプリンタ等の出力装置６６と、ＩＣカード等の可搬性を有する記憶媒体６８から情報を読み取る読取装置６７と、これらの各装置間のデータ送受を行うインタフェース６０とを備えた、電子計算機において、ＣＰＵ６１がメモリ６２上にロードされた所定のプログラムを実行することにより、実現できる。

これらのプログラムは、あらかじめ、上記電子計算機内のメモリ６２または外部記憶装置６３に格納されていても良いし、必要なときに、上記電子計算機が利用可能な、着脱可能な記憶媒体６８または通信媒体（ネットワークやＬＡＮ６９またはそれらの上を伝搬する搬送波）を介して、導入されてもよい。

なお、本実施例では、端末は、図１６に示されるような構成により実現できるとしているが、本発明はそれに限定されるものではない。図１に示す端末２_１、から端末２_８、の各機器は、サイト内ネットワークと接続することのできる通信装置を備えた機器であってもよい。例えば、ルータ、ＰＣ、携帯電話、ＰＤＡ、テレビ、冷蔵庫などの家電製品も、端末となりうる。

次に本実施例による通信システムの動作について説明する。

本実施の形態におけるセキュア通信システムは、サイトＡ内の端末２が、サイトＡ内ネットワーク４１、サイト外ネットワーク４０、サイトＢ内ネットワーク４２を介して、サイトＢ内の端末２と、セキュア通信を行うシステムである。ここでは、端末２_１が端末２_２に対し、セキュア通信の要求を行い、セキュア通信を終えるまでの動作を示す。

まず、端末２_１と、端末２_２がセキュア通信を行う場合、端末２_１と端末２_２は、図２に示すフローに従い、公開鍵証明書５０９_１と公開鍵証明書５０９_２を交換する。

端末２_１は、端末２_２の公開鍵証明書５０９_２の要求を端末２_２に送信する（ステップ１０００）
端末２_２は、端末２_１から送られてきた公開鍵証明書５０９_２の要求を受信する（ステップ１００２）
ステップ１００２で要求を受けた公開鍵証明書５０９_２を保持している場合（ステップ１００４でYES）は、端末２_２は、端末２_２の公開鍵証明書５０９_２と、端末２_１の公開鍵証明書５０９_１の要求を、端末２_１に送信する（ステップ１００６）。

端末２_１は、端末２_２の公開鍵証明書５０９_２と、端末２_１の公開鍵証明書５０９_１の要求を、端末２_２から受信する（ステップ１００８）
ステップ１０１０で要求を受けた公開鍵証明書５０９_１を保持している場合（ステップ１０１０でYES）は、端末２_１は、端末２_１の公開鍵証明書５０９_１を、端末２_２に送信する（ステップ１０１２）。

端末２_２は、端末２_１の公開鍵証明書５０９_１を、端末２_１から受信する（ステップ１０１４）
端末２_２は、端末２_１の公開鍵証明書５０９_１を、受信したことを、端末２_１に通知するために、端末２_１の公開鍵証明書５０９_１の受信通知を、端末２_１に送信する（ステップ１０１６）。

端末２_１は、端末２_１の公開鍵証明書５０９_１の受信通知を、端末２_２より受信する（ステップ１０１８）。

上記ステップ１００４または、ステップ１０１０でNOの場合（公開鍵証明書を保持していない場合）は、図１７のステップ１３１６（Ａ）へ進み、セキュア通信を切断する処理を行う。ただし、図１７は端末２_１から通信終了を要求する場合を示しており、ステップ１００４から進む場合は、端末２_２が通信終了要求を出すので、端末２_１と端末２_２との動作が入れ替わる。

上記処理を行うことにより、端末２_１と、端末２_２は、公開鍵証明書５０９_１と５０９_２を交換する。

次に、端末２_１と端末２_２はそれぞれ、図３に示すフローに従い、所属するサイトの認証サーバ３_１、３_２に、通信先端末２_２、２_１との通信許可をもとめ、可否判定を受け取る。

図３は、端末２_１が認証サーバ３_１に通信許可を求める場合を示すが、端末２_２が認証サーバ３_２に通信許可をもらう場合も、同様の手順を行う。

端末２_１は、認証サーバ３_１に端末２_２との通信許可を求めるために、通信元端末である端末２_１の公開鍵証明書５０９_１と通信先である端末２_２の公開鍵証明書５０９_２を認証サーバ３_１に送信する（ステップ１１００、ステップ１１０４）
認証サーバ３_１は、公開鍵証明書５０９_１と、公開鍵証明書５０９_２を、受信する（ステップ１１０２、ステップ１１０６）
このとき、公開鍵証明書５０９_２を送った後で、公開鍵証明書５０９_１を送っても良い。あるいは、二つの公開鍵証明書を同時に送っても良い。

認証サーバ３_１は、アクセス制御機能３０２_１により、問い合わせを受けたセキュア通信が、接続ポリシー３０_１で許可されているかどうかを判定する。具体的には、ステップ１１０２、ステップ１１０６で受信した公開鍵証明書５０９_１から、通信元と通信先のデータを取り出す。

次に、設定する接続ポリシー（許可）３１２で許可されているかどうかを調べる。なお、本実施例では、設定する接続ポリシー（許可）３１２は、複数のエントリが存在する場合があり、その場合には、一行に一エントリを記載し、より下の行のエントリが、優先して適用される、としている。すなわち、エントリが複数ある場合には、それぞれのエントリの情報を、ポリシーの情報を保管するファイルの先頭から後へ（上から下へ）順に保存し、より後方に（下方に）保管されたエントリが、優先して適用される、とする。このため、一番下のエントリから順に、接続要求が接続ポリシーエントリに合致するか調べ、合致した時点で、接続可と判定する。もし、いずれかのポリシーに合致しない場合には、デフォルトのポリシー３１０により、通信拒否と判定する。（ステップ１１０８）。

なお、意図した通信許可判定１１０８が行えるようにあらかじめ、エントリの優先順位を決めておき、優先順位の低い順に、当該ファイルの先頭から後へ、エントリを保存する。

接続ポリシー３０で許可されていない場合は（ステップ１１１０でNO）、ステップ１１２０へ進む。

許可されている場合には（ステップ１１１０でYES）、端末２_１から送られてきた、公開鍵証明書５０９_１を検証する。公開鍵証明書５０９_１の検証では、有効期限、署名、公開鍵証明書失効リストを検証する（ステップ１１１２）。

公開鍵証明書５０９_１の検証１１１２が成功しなかった場合は（ステップ１１１４でNO）、ステップ１１２０へ進む。

公開鍵証明書５０９_１の検証１１１２が成功した場合は（ステップ１１１４でYES）、公開鍵証明書５０９_２を検証する。公開鍵証明書５０９_２の検証では、有効期限、署名、公開鍵証明書失効リストを検証する（ステップ１１１６）。

通信先すなわち端末２_２の公開鍵証明書５０９_２の検証１１１６が成功しなかった場合は（ステップ１１１８でNO）、ステップ１１２０へ進む。

通信先すなわち端末２_２の公開鍵証明書５０９_２の検証１１１６が成功した場合は（ステップ１１１８でYES）、認証サーバ３_１の署名を付与した、接続許可通知を端末２_１に対して送信する（ステップ１１２２）。

ステップ１１２０では、認証サーバ３_１の署名を付与した、接続不可通知を端末２_１に対して送信する。

端末２_１はステップ１１２０あるいは１１２２で送信された、接続不可通知あるいは接続許可通知を受信し、通知に付与された認証サーバ３_１の署名を検証することにより、通知が確かに認証サーバ３_１から送付されたことを確認する（ステップ１１２４）。

端末２_１は、接続許可通知を受け取った場合は（ステップ１１２６でYES）、図４の（Ｃ）へ処理を進める。

端末２_１は、接続不可通知を受け取った場合は（ステップ１１２６でNO）、セキュア通信を切断するために、図１７のステップ１３１６（Ａ）に進む。

それぞれが所属するサイトの認証サーバ３_１、３_２より通信可の判定を受け取った端末２_２、２_１は、図４に示すように、互いに、ＩＤに電子署名を添付し、電子署名を添付したＩＤを交換し、交換した電子署名を検証することで、通信相手を認証し、その後、鍵共有を行う。

まず、端末２_１は端末２_１のＩＤに対して、電子署名を生成し、ＩＤに生成した電子署名を添付して、端末２_２に送信する（ステップ１２００）
端末２_２は、電子署名を添付した端末２_１のＩＤを端末２_１から受信する（ステップ１２０２）
端末２_２は、受信した電子署名をステップ１０１８で受信した端末２_１の公開鍵証明書５０９_１の公開鍵を用いて、検証する（ステップ１２０４）
電子署名の検証に成功した場合は（ステップ１２０６でYES）、端末２_２のＩＤに対して、電子署名を生成し、ＩＤに生成した電子署名を添付して、端末２_１に送信する（ステップ１２０８）。

端末２_１は、電子署名を添付した端末２_２のＩＤを端末２_２から受信する（ステップ１２１０）
端末２_１は、受信した電子署名をステップ１０１０で受信した端末２_２の公開鍵証明書５０９_２の公開鍵を用いて、検証する（ステップ１２１２）
端末２_１は、電子署名の検証に成功した場合は（ステップ１２１４でYES）、暗号化通信を行うための複数の暗号化通信パラメータの候補を端末２_２に送信する（ステップ１２１６）。

端末２_２は、端末２_１から暗号化通信パラメータの候補を受信する（ステップ１２１８）
端末２_２は、受信した暗号化通信パラメータの候補の中から、１つ選択し、選択した暗号化通信パラメータを、端末２_１に送信する（ステップ１２２０）。

端末２_１は、端末２_２から選択した暗号化通信パラメータを受信する（ステップ１２２２）
端末２_１は、端末２_２から選択した暗号化通信パラメータを受信した確認メッセージを端末２_２に送信する（ステップ１２２４）
端末２_２は、端末２_１から選択した暗号化通信パラメータ受信の確認メッセージを端末２_１から受信する（ステップ１２２６）。

ステップ１２０６またはステップ１２１４でNOの場合（電子署名の検証に失敗した場合）は、セキュア通信を切断するために、図１７のステップ１３１６に進む（Ａ）。ただし、図１７は端末２_１から通信終了を要求する場合を示しており、ステップ１２０６から進む場合は、端末２_２が通信終了要求を出すので、端末２_１と端末２_２との動作が入れ替わる。

以上の処理で、端末２_１と端末２_２は暗号化通信時に用いる暗号化通信パラメータを共有することができる。

次に端末２_１は、暗号化通信用の端末２_２と共通の鍵を暗号化通信パラメータを基に生成する（ステップ１２２８）。その後、暗号化通信のためのコネクションを確立する手続きＤへ進む。端末２_２は、暗号化通信用の端末２_１と共通の鍵を暗号化通信パラメータを基に生成する（ステップ１２３０）。その後、暗号化通信のためのコネクションを確立する手続きＥへ進む。以上で、通信相手の認証と鍵共有が完了する。

通信相手が認証できたら、通信コネクションを確立し、暗号化通信を行う。

図５は、暗号化通信を行うための、コネクションを確立し、暗号化通信を行い、暗号化通信終了時に、コネクションを切断するステップを示したシーケンス図である。

端末２_１、端末２_２にデータ転送許可要求を送信し（ステップ１３００）、
端末２_２は、これを受信する（ステップ１３０２）。

端末２_２は、端末２_２のデータ転送許可と、端末２_１へのデータ転送許可要求を、端末２_１へ送信し（ステップ１３０４）、
端末２_１は、これらを受信する（ステップ１３０６）。

端末２_１は、端末２_２のデータ転送許可を、端末２_２へ送信し（ステップ１３０８）、
端末２_２は、これを受信する（ステップ１３１０）。

上記処理により、端末２_１と、端末２_２は、お互いにデータ転送許可を出したので、コネクションが確立する（ステップ１３１２）。

コネクション確立後は、図４のステップ１２２０、ステップ１２２２で共有した、暗号化通信パラメータと、ステップ１２２８とステップ１２３０で生成した鍵を用いて、端末２_１と、端末２_２は、暗号化通信を行う（ステップ１３１４）。

暗号化通信が終了したら、図１７に示すシーケンスに従って、コネクションを切断する。

暗号化通信を終える場合には、まず、端末２_１は、端末２_２との、通信終了要求を端末２_２に送信し（ステップ１３１６）、
端末２_２は、これを受信する（ステップ１３１８）。

端末２_２は、通信終了許可と、通信終了許可要求を端末２_１へ送信し（ステップ１３２０）、
端末２_１は、これらを受信する（ステップ１３２２）。

端末２_１は、通信終了許可を端末２_２へ送信し（ステップ１３２４）、端末２_２は、これを受信する（ステップ１３２６）。

上記処理により、端末２_１と、端末２_２は、お互いに通信終了許可を受信したので、コネクション切断が完了する（ステップ１３２８）。

次に接続ポリシー３０を設定する動作について説明する。

図１１は、図１の接続ポリシー管理機能３０３_１の手順を示す図である。

まず、サイトＡの管理者は、サイトＡで、接続ポリシー（拒否）３１０あるいは、接続ポリシー（許可）３２０のどちらをデフォルトとして採用するか決めて設定する（ステップ３０００）。

図６の接続ポリシーを選択した場合は、設定する接続ポリシー（許可）３１２に接続ポリシーのエントリ３１３を追加する。図７の接続ポリシーを選択した場合は、設定する接続ポリシー（拒否）３２２に接続ポリシーのエントリ３２３を追加する（ステップ３００２）。

ステップ３００２は必要な設定接続ポリシーの数だけ、繰り返す（ステップ３００４）。

以上が、接続ポリシー３０を設定するシーケンスである。

端末がサービスを提供する場合の接続ポリシー３０を設定するには、図１１のステップ３０００で、デフォルトの接続ポリシー３５０を設定し、上記シーケンス同様、設定する接続ポリシー３５４の追加を繰り返せばよい。

サイトＡ内では、認証サーバ３_１が接続ポリシー３０を集中管理するので、サイトＡの管理者は、認証サーバ３_１の接続ポリシー３０_１を管理しておけばよい。変更が必要になった場合は、認証サーバ３_１の接続ポリシー３０_１を書き換えることにより、サイトＡ内のすべての端末２_１、２_３、２_４、２_５に、変更後の接続ポリシー３０_１が、すぐに適用される。

図１２に接続ポリシーの変更の手順を示す。

まず、図６の接続ポリシーから、図７の接続ポリシー、あるいは、図７の接続ポリシーから、図６の接続ポリシーへ変更する場合は（ステップ３１００でYES）、現在認証サーバ３_１で保持している接続ポリシーを一度すべて、削除する（ステップ３１０２）
その後、接続ポリシーの設定手順３０００から３００４を実行する（ステップ３１０４）。

デフォルトの接続ポリシーを変更しない場合は（ステップ３１００でNO）、現在設定している接続ポリシーエントリで、不必要なものがあれば削除する（ステップ３１０６）
設定する接続ポリシーで、接続ポリシーエントリ３１３や３２３の項目に修正が必要なものがある場合は、修正する（ステップ３１０８）。

設定する接続ポリシーのエントリの優先順位を決める（ステップ３１１０）。設定する接続ポリシーエントリが複数ある場合には、一行に一エントリを記載し、より下の行に記載したエントリが、より上の行に記載したエントリに優先して適用される。すなわち、エントリが複数ある場合には、それぞれのエントリの情報を、ポリシーの情報を保管するファイルの先頭から後へ（上から下へ）順に保存し、より後方に（下方に）保管されたエントリが、優先して適用される、とする。

ステップ３１１０で接続ポリシーのエントリの順番を入れ替え、接続ポリシーエントリの優先順位を設定する。

端末がサービスを提供する場合の図１０の接続ポリシーを変更するには、図１２のステップを同様に行う。

なお、本実施例では、サイトＡ内の端末とサイトＢ内の端末間のセキュア通信について説明しているが、例えば、サイトＡ内の端末２_３と端末２_４がお互いに相手を認証することにより、サイト内のセキュア通信を行うこともできる。

また、本実施例では、認証局が端末２_１、２_２に対して公開鍵証明書を発行するとしているが、例えば、認証局から、端末２_１のユーザに対して、公開鍵証明書５０９_１を発行してもよい。この場合は、端末２_１は、端末２_１を利用するユーザの公開鍵証明書５０９_１を保管する。ユーザが、端末２_１に保管された公開鍵証明書５０９_１にアクセスする際、端末２_１が、ユーザを認証することにより、正しいユーザが、正しい公開鍵証明書５０９_１にアクセスすることができる。ユーザは、端末に保管された公開鍵証明書５０９_１を用いて、端末２_１と端末２_２の間のセキュア通信を行う。

さらには、認証局は、組織あるいはグループに対して1枚あるいは、複数枚の公開鍵証明書を発行してもよい。組織あるいは、グループのメンバは、公開鍵証明書を用いて、セキュア通信を行う。公開鍵証明書が複数枚発行されている場合は、端末を利用するユーザによって、利用する公開鍵証明書を切り替えて、セキュア通信を行うことができる。

また、本実施例では、上記のように、公開鍵証明書５０９_１は端末２_１に保管されるとしているが、可搬性を有する記憶媒体に保管しても良い。これにより、図１３に示すように、記憶媒体を挿入した端末から、セキュア通信を行うことができる。

図１３では、認証局が、ユーザ２０_１に発行した公開鍵証明書５０９_９は、ユーザ２０_１が所有する可搬性を有する記憶媒体２１_１に保管される。ユーザ２０_１は記憶媒体２１_１を端末２_１に挿入することにより、端末２_１を利用して、端末２_２とセキュア通信を行うことができる。ユーザ２０_１が、記憶媒体２１_１を所有するため、公開鍵証明書５０９_９と、ユーザ２０_１との１対１関係ができる。

同様に、認証局が、ユーザ２０_２に発行した公開鍵証明書５０９_１０は、ユーザ２０_２が所有する記憶媒体２１_２に保管される。ユーザ２０_２は記憶媒体２１_２を端末２_１に挿入することにより、端末２_１を利用して、端末２_２とセキュア通信を行うことができる。上記のように、複数のユーザ２０_１と、２０_２が、一つの端末２_１を利用することもできる。

さらに、図７において、ユーザ２０_１は、複数の公開鍵証明書を、記憶媒体２１_１内に保有することができる。記憶媒体２１_１を端末２_１に挿入し、保管されている公開鍵証明書のうちの一つを用いて、端末２_２とセキュア通信を行うこともできる。

また、本実施例では、端末２_１が、認証サーバ問い合せ機能２０３_１を搭載しているが、例えば、サイトＡ内ネットワーク４１とサイトＡ外のネットワーク４０の間にルータを設置し、当該ルータは、端末２と同様の機能を保持するようにしてもよい。さらに、図１４に示すように、端末２_１が、認証サーバ３_１に接続可否を問い合わせた場合、端末２_１とサイトＡのルータが接続可否通知を受け取ることもできる。

端末２_１は、端末２_１と端末２_２の公開鍵証明書を、認証サーバ３_１に送信する（ステップ２０００）
認証サーバ３_１は、端末２_１と端末２_２の公開鍵証明書を端末２_１から受信する（ステップ２００２）
認証サーバ３_１は、接続ポリシー３０_１を参照し合致しているか調べ、端末２_１と端末２_２の公開鍵証明書を検証し、接続可否判定を行う（ステップ２００４）。

認証サーバ３_１は、接続可否判定を、端末２_１とサイトＡのルータに送信する（ステップ２００６）
端末２_１は、認証サーバ３_１より、接続可否通知を受信する（ステップ２００８）
サイトＡのルータも認証サーバ３_１より、接続可否通知を受信する（ステップ２０１０）
端末２_１は、接続拒否の判定を受信した場合は、ステップ１３１６で通信の終了処理を行う。また、サイトＡのルータが、接続拒否の判定を受信したときに、サイトＡのルータが、強制的に通信の切断処理をおこなうこともできる。

また、図１５に示すように、サイトＡのルータが、認証サーバ３_１に接続可否を問い合わせることもできる。

サイトＡのルータは、図２のシーケンスで証明書を載せたパケットがルータを通過する際、端末２_１と端末２_２の公開鍵証明書を取り出し、認証サーバ３_１に送信する（ステップ２０００）
認証サーバ３_１は、端末２_１と端末２_２の公開鍵証明書をサイトＡのルータから受信する（ステップ２００２）
認証サーバ３_１は、接続ポリシー３０_１を参照し合致しているか調べ、端末２_１と端末２_２の公開鍵証明書を検証し、接続可否判定を行う（ステップ２００４）。

認証サーバ３_１は、接続可否判定を、端末２_１とサイトＡのルータに送信する（ステップ２００６）
端末２_１は、認証サーバ３_１より、接続可否通知を受信する（ステップ２００８）
サイトＡのルータも認証サーバ３_１より、接続可否通知を受信する（ステップ２０１０）
端末２_１は、接続拒否の判定を受信した場合は、ステップ１３１６で通信の終了処理を行う。また、サイトＡのルータが、接続拒否の判定を受信したときに、サイトＡのルータが、強制的に通信の切断処理をおこなうこともできる。

このように、端末２_１が仮に、不正に端末２_２とセキュア通信しようとした場合にも、サイトＡのルータが強制的に通信の切断処理を行うことができる。

本発明の一実施形態におけるセキュア通信システムの構成を示す図である。 端末２_１と端末２_２が公開鍵証明書を交換する処理手順を示すフローチャートである。 端末２_１が認証サーバ３_１へ接続許可を問い合わせ、認証サーバ３_１が端末２_１に接続可否通知を返答する処理手順を示すフローチャートである。 端末２_１と端末２_１が電子署名を用いてお互いに相手を認証し、端末２_１と端末２_１が各々、暗号化通信用の鍵を生成する処理手順を示すフローチャートである。 端末２_１と端末２_１がコネクションを確立し、暗号化通信を行うまでの処理手順を示すフローチャートである。 認証サーバ３_１、３_２が保持する接続を許可する接続ポリシーのリストである。 認証サーバ３_１、３_２が保持する接続を拒否する接続ポリシーのリストである。 図６、図７に示す接続ポリシーを構成する通信元と通信先の例を示す表である。 端末２_１が提供するサービスＩＤとサービスメニューの対応関係を示す表である。 認証サーバ３_１が保持する端末２_１の接続ポリシーのリストである。 認証サーバ３_１、３_２の接続ポリシー管理機能における接続ポリシーの設定手順を示したフローチャートである。 認証サーバ３_１、３_２の接続ポリシー管理機能における接続ポリシーの変更手順を示したフローチャートである。 公開鍵証明書をユーザが所有する可搬性を有する記憶媒体に保管し、記憶媒体を端末に挿入することにより、端末で公開鍵証明書を利用する場合を示す図である。 端末２_１から認証サーバ３_１に問い合わせを行い、端末２_１とサイトＡのルータに通信可否判定を返すフローチャートである。 サイトＡのルータから認証サーバ３_１に問い合わせを行い、端末２_１とサイトＡのルータに通信可否判定を返すフローチャートである。 端末２_１〜２_８、認証サーバ３_１、３_２の各々のハードウェア構成例を示す図である。 端末２_１と端末２_１がコネクションを切断する処理手順を示すフローチャートである。

符号の説明

２_１〜２_８…端末、２０_１、２０_２…ユーザ、２１_１、２１_２…可搬性を有する記憶媒体、３_１、３_２…認証サーバ、３０…インタフェース、３１…ＣＰＵ、３２…メモリ、３３…外部記憶装置、３４…通信装置、３５…入力装置、３６…出力装置、３７…読取装置、３８…可搬性を有する記憶媒体、４０…サイト外ネットワーク、４１…サイトＡ内ネットワーク、４２…サイトＢ内ネットワーク、５０９_１〜５０９_１０…公開鍵証明書。

Claims (10)

1. 通信元端末と、当該通信元端末とは異なるサイトに所属する通信先端末と、が通信を行う、通信システムであって、
   前記通信元端末が属するサイトに、前記通信元端末から前記通信先端末へのアクセスの可否を判定する第一の認証サーバを備え、
   前記通信元端末は、当該第一の認証サーバに前記通信先端末へのアクセスの可否を問い合わせる、
   ことを特徴とする通信システム。
2. 請求項１に記載の通信システムであって、
   前記通信先端末が属するサイトに、前記通信元端末から前記通信先端末へのアクセス受け付けの可否を判定する第二の認証サーバ、を備え、
   前記通信先端末は、前記第二の認証サーバに前記通信元端末からのアクセス受け付け可否を問い合わせる、
   ことを特徴とする通信システム。
3. 請求項１に記載の通信システムであって、
   前記通信元端末が、当該第一の認証サーバに前記通信先端末への前記アクセスの可否を問い合わせる場合に、前記第一の認証サーバに、当該通信元端末あるいは当該通信元端末を利用するユーザの公開鍵証明書、と前記通信先端末の公開鍵証明書、を添付して問い合わせる
   ことを特徴とする通信システム。
4. 請求項２に記載の通信システムであって、
   前記通信先端末が、前記通信元端末から、アクセスを受けた場合に、当該アクセスを受け付けてよいか否かを、前記第二の認証サーバに、前記通信元端末あるいは前記通信元端末を利用するユーザの公開鍵証明書、と当該通信先端末の公開鍵証明書、を添付して問い合わせる、
   ことを特徴とする通信システム
5. 請求項３に記載の通信システムであって、
   前記第一の認証サーバは、
   前記アクセスの可否を判定するために、予め定められた接続ポリシーを保持しており、
   当該接続ポリシーに適合し、前記通信元端末あるいは前記通信元端末を利用するユーザの公開鍵証明書、と前記通信先端末の公開鍵証明書の検証に成功した場合に、前記アクセスの許可通知を前記通信元端末に返信する、
   ことを特徴とする通信システム。
6. 請求項４に記載の通信システムであって、
   前記第二の認証サーバは、
   前記アクセス受け付けの可否を判定するために、予め定められた接続ポリシーを保持しており、
   当該接続ポリシーに適合し、前記通信元端末あるいは前記通信元端末を利用するユーザの公開鍵証明書、と前記通信先端末の公開鍵証明書の検証に成功した場合に、前記アクセス受け付け許可通知を前記通信先端末に返信する、
   ことを特徴とする通信システム。
7. 二つの異なるサイトに所属する複数の通信端末が通信を行う、通信システムに用いられる認証サーバであって、
   当該認証サーバが属するサイト内の通信端末から、他のサイトに属する通信端末との通信可否を判断する
   ことを特徴とする認証サーバ。
8. 請求項７に記載の認証サーバであって、
   前記通信可否の問い合せには、当該通信可否の問い合せを行った、第一の前記通信端末が保持している、第一の公開鍵証明書と、前記第一の通信端末が通信しようとしている、第二の前記通信端末が保持している、第二の公開鍵証明書と、が含まれており、
   当該認証サーバは、第一の公開鍵証明書が有効であり、かつ、第二の公開鍵証明書が有効である場合に、前記通信を許可する
   ことを特徴とする認証サーバ。
9. 請求項７に記載の認証サーバであって、
   前記通信可否の問い合せには、前記第一の通信端末を利用するユーザが保持している、第三の公開鍵証明書と、前記第二の公開鍵証明書と、が含まれており、
   当該認証サーバは、前記第三の公開鍵証明書が有効であり、かつ、前記第二の公開鍵証明書が有効である場合に、前記通信を許可する
   ことを特徴とする認証サーバ。
10. 請求項９に記載の認証サーバであって、
    前記通信可否を判定するために、予め定められた接続ポリシーを保持しており、
    前記通信可否の問い合わせに対して、通信要求が当該接続ポリシーに適合している場合に、前記通信を許可する
    ことを特徴とする認証サーバ。
    

Images