(57)【要約】【課題】  通信先端末が、セキュア通信の要求を通信元端末から受けた場合に、当該通信要求を受け付けてよいか判定することや、通信元端末が正しいかどうか認証することができない。また、通信元端末が通信先端末へセキュア通信を行おうとする場合に、通信元端末は、接続相手である通信先端末が正しい接続相手であるかどうか判定することができない。【解決手段】  通信元端末が所属するサイトに認証サーバを置き、通信元端末は、通信元端末が所属するサイトの認証サーバにアクセス可否を問い合わせる。また、通信先端末が所属するサイトに認証サーバを置き、通信先端末は、通信先端末が所属するサイトの認証サーバにアクセス可否を問い合わせる。【選択図】図１
2005217679.tif 000002
【特許請求の範囲】
【請求項１】
通信元端末と、当該通信元端末とは異なるサイトに所属する通信先端末と、が通信を行う、通信システムであって、
前記通信元端末が属するサイトに、前記通信元端末から前記通信先端末へのアクセスの可否を判定する第一の認証サーバを備え、
前記通信元端末は、当該第一の認証サーバに前記通信先端末へのアクセスの可否を問い合わせる、
ことを特徴とする通信システム。
【請求項２】
請求項１に記載の通信システムであって、
前記通信先端末が属するサイトに、前記通信元端末から前記通信先端末へのアクセス受け付けの可否を判定する第二の認証サーバ、を備え、
前記通信先端末は、前記第二の認証サーバに前記通信元端末からのアクセス受け付け可否を問い合わせる、
ことを特徴とする通信システム。
【請求項３】
請求項１に記載の通信システムであって、
前記通信元端末が、当該第一の認証サーバに前記通信先端末への前記アクセスの可否を問い合わせる場合に、前記第一の認証サーバに、当該通信元端末あるいは当該通信元端末を利用するユーザの公開鍵証明書、と前記通信先端末の公開鍵証明書、を添付して問い合わせる
ことを特徴とする通信システム。
【請求項４】
請求項２に記載の通信システムであって、
前記通信先端末が、前記通信元端末から、アクセスを受けた場合に、当該アクセスを受け付けてよいか否かを、前記第二の認証サーバに、前記通信元端末あるいは前記通信元端末を利用するユーザの公開鍵証明書、と当該通信先端末の公開鍵証明書、を添付して問い合わせる、
ことを特徴とする通信システム
【請求項５】
請求項３に記載の通信システムであって、
前記第一の認証サーバは、
前記アクセスの可否を判定するために、予め定められた接続ポリシーを保持しており、
当該接続ポリシーに適合し、前記通信元端末あるいは前記通信元端末を利用するユーザの公開鍵証明書、と前記通信先端末の公開鍵証明書の検証に成功した場合に、前記アクセスの許可通知を前記通信元端末に返信する、
ことを特徴とする通信システム。
【請求項６】
請求項４に記載の通信システムであって、
前記第二の認証サーバは、
前記アクセス受け付けの可否を判定するために、予め定められた接続ポリシーを保持しており、
当該接続ポリシーに適合し、前記通信元端末あるいは前記通信元端末を利用するユーザの公開鍵証明書、と前記通信先端末の公開鍵証明書の検証に成功した場合に、前記アクセス受け付け許可通知を前記通信先端末に返信する、
ことを特徴とする通信システム。
【請求項７】
二つの異なるサイトに所属する複数の通信端末が通信を行う、通信システムに用いられる認証サーバであって、
当該認証サーバが属するサイト内の通信端末から、他のサイトに属する通信端末との通信可否を判断する
ことを特徴とする認証サーバ。
【請求項８】
請求項７に記載の認証サーバであって、
前記通信可否の問い合せには、当該通信可否の問い合せを行った、第一の前記通信端末が保持している、第一の公開鍵証明書と、前記第一の通信端末が通信しようとしている、第二の前記通信端末が保持している、第二の公開鍵証明書と、が含まれており、
当該認証サーバは、第一の公開鍵証明書が有効であり、かつ、第二の公開鍵証明書が有効である場合に、前記通信を許可する
ことを特徴とする認証サーバ。
【請求項９】
請求項７に記載の認証サーバであって、
前記通信可否の問い合せには、前記第一の通信端末を利用するユーザが保持している、第三の公開鍵証明書と、前記第二の公開鍵証明書と、が含まれており、
当該認証サーバは、前記第三の公開鍵証明書が有効であり、かつ、前記第二の公開鍵証明書が有効である場合に、前記通信を許可する
ことを特徴とする認証サーバ。
【請求項１０】
請求項９に記載の認証サーバであって、
前記通信可否を判定するために、予め定められた接続ポリシーを保持しており、
前記通信可否の問い合わせに対して、通信要求が当該接続ポリシーに適合している場合に、前記通信を許可する
ことを特徴とする認証サーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信時にアクセス制御を行うサーバに関し、特に、公開鍵証明書と、接続ポリシーを利用して通信可否を判断するサーバに関する。
【背景技術】
【０００２】
ネットワークを通じたセキュア通信は、データを暗号化して送受信することにより実現される。セキュア通信は、以下の手順で実現される。
【０００３】
まず、セキュア通信を行う端末は、通信相手が意図した相手であることを確認するために、通信相手を認証する。通信相手の認証に成功すると、暗号鍵の共有を行い、共有した鍵を用いて、お互いの通信データの暗号化を行う。
【０００４】
セキュア通信において通信相手の認証を行うために、電子署名を用いる方法がある。電子署名では、公開鍵と秘密鍵のペアを用いる公開鍵暗号技術が利用されている。
【０００５】
電子署名について簡単に説明すると以下のようである。
【０００６】
署名者は署名者のＩＤに対して署名者の秘密鍵で電子署名を生成する。次に、署名者のＩＤに電子署名を付与して検証者に送る。一方、検証者は、署名者から送られてきた電子署名を当該署名者の公開鍵によって検証することにより、受け取ったＩＤが改ざんされることなく、署名者から送られてきたことが確認でき、署名者を認証することができる。
【０００７】
上記公開鍵が署名者のものであることを証明するために、公開鍵証明書が用いられることが多い。公開鍵証明書には上記公開鍵や当該公開鍵の所有者などの情報が含まれており、認証局と呼ばれる証明書発行機関において電子署名が付与されたものである。
【０００８】
公開鍵証明書には、有効期限が定められている。また、有効期限内であっても様々な理由により失効することがある。このため、公開鍵が確かに署名者のものであることを確認するためには、検証者が署名者の公開鍵証明書が有効であることを検証することが必要である。
【０００９】
公開鍵証明書を検証するには、公開鍵証明書に付与されている認証局の署名が正しいことや、公開鍵証明書が有効期限内であること、公開鍵証明書が失効していないことを確認する必要がある。
【００１０】
ネットワークを通じたセキュア通信を行う場合には、通信元端末と通信先端末とが、一方が署名者の場合は他方が検証者となり、それぞれ署名者と検証者の立場を替えて、お互いに通信相手の認証を行う。
【００１１】
また、ネットワークを通じたセキュア通信では、あらかじめアクセスを許す相手を定めた接続ポリシーを決めておくことで、セキュア通信を許可する端末を制限するといった、アクセス制御を行う方法が用いられることがある。端末で、電子署名を用いた相手認証とアクセス制御を同時に行えば、あらかじめ定めておいた相手とのみセキュア通信ができる。
【００１２】
ただし、端末で電子署名を用いた相手認証を行うには、通信相手の公開鍵証明書の検証が必要であり、端末にとって処理負荷が大きい、という課題がある。また、端末がアクセス制御を行うためには、端末ごと接続ポリシーを設定することになり、接続ポリシーの集中管理ができない、という課題がある。これらの課題を解決するために、公開鍵証明書の検証とアクセス制御の機能をサーバで行う方法が提案されている(例えば特許文献１など)。
【００１３】
特許文献１では、企業外のネットワークに接続しているクライアントから、企業ネットワークシステムの業務サーバにアクセスする際に、公開鍵証明書を用いて認証を行う。
【００１４】
【特許文献１】特開２０００−１０９３０号公報
【発明の開示】
【発明が解決しようとする課題】
【００１５】
特許文献１の手法は、ネットワークを通じたセキュア通信に適用することができる。あるサイトに所属する通信元端末のユーザが、別のサイトに所属する通信先端末とセキュア通信を行うとする。通信元端末のユーザは、通信元端末を介して、通信先端末とセキュア通信を行うために、以下のステップを行う。
【００１６】
通信元端末は、通信先端末が所属するサイトのアクセス制御サーバに、ユーザの通信先端末へのアクセス可否の判定要求を送る。アクセス制御サーバは、アクセス可否を判定し、判定結果を通信元端末に返す。ユーザの通信先端末へのアクセス判定が、可であれば、ユーザは、通信元端末から通信先端末へアクセスする。一方、ユーザの通信先端末へのアクセス判定が否であれば、通信元端末は通信先端末へのアクセスを行わない。
【００１７】
上記特許文献１で提案されている技術をセキュア通信に適用した場合、通信元端末がアクセス制御サーバの判定に基づいて通信先端末にアクセスするか否かを決定する。しかし、通信先端末が、セキュア通信の要求を通信元端末から受けた場合に、当該通信要求を受け付けてよいか判定することや、通信元端末が正しいかどうか認証することについては、特許文献１では言及していない。
【００１８】
また、通信元端末を利用するユーザが正しいかどうか認証する手段についても、特許文献１では言及していない。
【００１９】
さらに、通信元端末が通信先端末へセキュア通信を行おうとする場合に、通信元端末またはそのユーザが、接続相手である通信先端末が正しい接続相手であるかどうか判定することについても、特許文献１では言及していない。
【００２０】
さらに、あるサイト内の通信元端末から別のサイトのアクセス制御サーバへ通信許可を求めるためには、通信元端末が所属するサイトと、アクセス制御サーバが所属するサイトとの間で、アクセス可否の問い合わせを行わなければならないが、特許文献１ではこの点について言及していない。
【課題を解決するための手段】
【００２１】
本発明は、通信元端末が所属するサイトと、通信先端末が所属するサイトとにそれぞれ認証サーバ装置（以下、認証サーバという）を置き、通信元端末と通信先端末は、それぞれが所属するサイトの認証サーバに通信可否、すなわち、アクセスまたはその受け付けの可否、を問い合わせる通信システムを提供する。
【００２２】
本発明におけるサイトとは、たとえば、企業や企業の部署等の組織単位のサブネットワーク、あるいは、特定のインターネットサービスプロバイダの会員の端末と当該プロバイダの回線からなるサブネットワーク、のような、特定のグループに所属するユーザのみが接続できるサブネットワークにおける端末やサーバを含むシステム全体を指す。また、特定のアドレス範囲で示される組織に所属する、端末やサーバを含むシステム全体を指す場合もある。
【００２３】
上記通信システムは、具体的には、通信先端末が、通信元端末あるいは通信元端末を利用するユーザから、通信の要求を受けた場合には、当該通信要求を受け付けてよいかどうかを、通信先端末が所属するサイトの認証サーバに、通信元端末あるいは通信元端末を利用するユーザの公開鍵証明書と、通信先端末の公開鍵証明書、を添付して問い合わせることを特徴とする。
【００２４】
上記認証サーバは、接続の可否を判定するために予め定められた接続ポリシーを保持しており、通信要求が当該接続ポリシーに適合しているかどうか判定する。次に、上記認証サーバは、通信要求に添付された公開鍵証明書の有効性を検証する。上記認証サーバは、当該接続ポリシーに適合し、公開鍵証明書の検証に成功した場合に、通信許可通知を通信先端末に返答する。
【００２５】
上記通信システムは、一方、通信元端末あるいは通信元端末を利用するユーザが、通信の要求を出そうとする場合には、当該通信要求を行ってよいかどうかを、通信元端末が所属するサイトの認証サーバに、通信元端末あるいは通信元端末を利用するユーザの公開鍵証明書、と通信先端末の公開鍵証明書、を添付して問い合わせることを特徴とする。
【００２６】
上記認証サーバは、通信要求を行ってよいかどうかを判定するために予め定められた接続ポリシーを保持しており、通信要求が当該接続ポリシーに適合しているかどうか判定する。次に、上記認証サーバは、通信要求に添付された公開鍵証明書の有効性を検証する。上記認証サーバは、当該接続ポリシーに適合し、公開鍵証明書の検証に成功した場合には、通信許可通知を通信元端末に返答する。
【００２７】
上記構成により、通信先端末が、通信の要求を通信元端末から受けた場合に、当該通信要求を受け付けてよいか判定することができ、また、通信元端末が正しいかどうか認証することができる。
【００２８】
また、通信元端末を利用するユーザが正しいかどうか認証することができる。
【００２９】
さらに、通信元端末が通信先端末へ通信を行おうとする場合に、通信元端末は、接続相手である通信先端末が正しい接続相手であるかどうか判定することができる。
【００３０】
また、通信元端末を利用するユーザが接続相手である通信先端末が正しい接続相手であるかどうか判定することができる。
【００３１】
なお、通信元端末とアクセス制御サーバ間の通信は、サイト内で行われるために、サイト管理者のアクセス制御サーバへの通信許可なしに、通信元端末とアクセス制御サーバの間は通信することができる。
【発明の効果】
【００３２】
本発明によれば、複数の通信端末は、互いに正しい相手通信端末との、安全な通信を行うことが可能になる。
【発明を実施するための最良の形態】
【００３３】
以下、本発明の実施の形態を詳細に説明する。なお、これによって本発明が限定されるものではない。
【００３４】
図１は、本発明の実施の一形態に係わるセキュア通信システムの構成を示すブロック図である。
【００３５】
図１のセキュア通信システムは、サイトＡ内のネットワーク４１に端末２１、端末２３、端末２４、端末２５、認証サーバ３１、が接続しており、サイトＢ内のネットワーク４２に端末２２、端末２６、端末２７、端末２８、認証サーバ３２、が接続している。サイトＡ内のネットワーク４１は、サイト外のネットワーク４０を介して、サイトＢ内のネットワーク４２に接続している。なお、以下、端末２１、端末２２、…、端末２８を総称して、端末２とも記述する。また、認証サーバ３１と認証サーバ３２とを総称して、認証サーバ３、とも記述する。
【００３６】
また、端末２１、端末２２、…、端末２８は、認証局からそれぞれ発行された公開鍵証明書５０９１、５０９２、…、５０９８を端末内に保管している。さらに、それぞれ、認証サーバに通信可否を問い合わせるための、認証サーバ問い合わせ機能２０３１、２０３２、…、２０３８と、暗号化通信に用いる鍵を共有するための、鍵共有機能２０２１、２０２２、…、２０２８と、他の端末とネットワークを介して通信するための、通信機能２０１１、２０１２、…、２０１８を備えている。
【００３７】
また、認証サーバ３１、３２は、接続可否の情報を記載した接続ポリシー３０１、３０２と、それぞれ公開鍵証明書の有効性を検証するための、証明書検証機能３０１１、３０１２と、通信可否の問い合わせが接続ポリシー３０１、３０２に合致しているか判定するための、アクセス制御機能３０２１、３０２２と、接続ポリシー３０１、３０２の作成や変更を行うための、接続ポリシー管理機能３０３１、３０３２、を備えている。なお、接続ポリシー３０１、接続ポリシー３０２を総称して、接続ポリシー３０とも記述する。
【００３８】
図６は、認証サーバ３１が備えている接続ポリシー３０１の一例である。
【００３９】
図６に示すように、認証サーバ３が保持する接続ポリシー３０は、デフォルトの接続ポリシー３１０と、それに優先する設定する接続ポリシー（許可）３１２からなる。デフォルトの接続ポリシー３１０は、通信元の端末２と、通信先の端末２と、通信を許可する期間と、を指定するものであり、具体的な内容は、全ての端末２から全ての端末２へのセキュア通信を無期限に拒否する、というものである。
【００４０】
接続ポリシー（許可）３１２は、複数のエントリから構成されており、一つのエントリは通信元の端末２と、通信先の端末２と、通信を許可する期間と、を指定する。接続ポリシー３１３は、設定する接続ポリシー（許可）３１２の一つのエントリである。接続ポリシー３１３では、端末２１と端末２２との接続を、２００２年１月１日から２００４年１２月３１日まで許可する、という接続ポリシー３０が記載されている。
【００４１】
なお、設定する接続ポリシー（許可）３１２は、接続ポリシー管理機能３０３１で編集することができる。
【００４２】
一方、接続ポリシー３０１として図６に示す接続ポリシー３０の代わりに図７に示すような、接続を拒否する端末２を指定する接続ポリシー３０を用いることもできる。図７における認証サーバ３が保持する接続ポリシー３０は、デフォルトの接続ポリシー３２０と、それに優先する設定する接続ポリシー３２２からなる。
【００４３】
図７におけるデフォルトの接続ポリシー３２０は、通信元の端末２と、通信先の端末２と、通信を許可する期間と、を指定するものであり、具体的な内容は、全ての端末２から全ての端末２へのセキュア通信を無期限に許可する、というものである。
【００４４】
図７における設定する接続ポリシー（拒否）３２２は、複数のエントリから構成されており、一つのエントリは通信元の端末２と、通信先の端末２と、通信を拒否する期間と、を指定する。接続ポリシー３２３は、設定する接続ポリシー（許可）３１２の一つのエントリである。接続ポリシー３２３では、端末２１と端末２２との接続を、２００２年１月１日から２００４年１２月３１日まで拒否する、という接続ポリシー３０が記載されている。
【００４５】
なお、設定する接続ポリシー（拒否）３２２は、接続ポリシー管理機能３０３１で編集することができる。
【００４６】
なお、上記説明では、認証サーバ３１の接続ポリシー３０１について説明したが、認証サーバ３２においても同様の形式で、接続ポリシー３０２を指定する。
【００４７】
なお、本実施例では、設定する接続ポリシー３１３あるいは、接続ポリシー３２３、で端末２１から端末２２へのセキュア通信に関する接続ポリシー３０を設定しているが、本発明はそれに限定されるものではない。例えば、通信元、あるいは通信先として、複数の端末２を一つのグループとして設定することができる。
【００４８】
図８の表３３０に示すように、端末２１から端末２２へのセキュア通信３３１、端末２１から端末２２と端末２６のグループへのセキュア通信３３２、端末２１と端末２３のグループから端末２２へのセキュア通信３３３、端末２１と端末２３のグループから端末２２と端末２６のグループへのセキュア通信３３４、に対して接続ポリシー３０を設定することもできる。
【００４９】
上述のグループとは、端末の集合のことであり、接続ポリシー３０で用いるグループとは、サイト全体、サイトに所属する各々の企業、企業内組織、（例えば、部、課、プロジェクトグループ）などのようなグループが考えられる。
【００５０】
このように、端末と端末の間のセキュア通信に限らず、端末と端末グループ間、端末グループと端末グループ間のセキュア通信においても、本実施例を適用することができる。
【００５１】
さらに、認証サーバ３の接続ポリシー３０を端末のサービス単位に設定することもできる。例えば、端末２１が図９に示すサービス１（３４１）、サービス２（３４２）、…を提供しており、それぞれのサービスには、サービスＩＤが割り当てられているとする。このとき、認証サーバ３１は図１０に示す接続ポリシー３０を設定すればよい。
【００５２】
具体的には、デフォルトの接続ポリシー３５０は、通信元端末２と、通信先端末２と、期間と、期間内にサービスを許可するのか拒否するのかと、を指定する。例えば、エントリ３５１では、端末２１のサービスＩＤ１へのアクセスは、無期限に拒否することを示している。
【００５３】
デフォルトの接続ポリシー３５０に優先する接続ポリシー３５４は、通信元端末２と、通信先端末２と、期間と、期間内にサービスを許可するのか拒否するのかと、を指定する。例えば、エントリ３５５では、端末２２から端末２１のサービスＩＤ１へのアクセスを２００２年１月１日から２００２年１月３１日まで許可することを示している。さらに、エントリ３５６では、端末２６から端末２１のサービスＩＤ１へのアクセスを２００２年１月１日午前０時から午後１１時５９分まで許可する。
【００５４】
したがって、接続ポリシー３５０により、端末２１のサービスＩＤ１に対しては、デフォルトで無期限に接続を拒否するが、それに優先する接続ポリシー３５４のエントリ３５５に指定した期間に限り、端末２２からの接続を許可し、エントリ３５６に指定した期間に限り、端末２６からの接続を許可する。
【００５５】
また、デフォルトの接続ポリシー３５０のエントリ３５２では、端末２１のサービスＩＤ１へのアクセスは、デフォルトで、無期限に許可する。デフォルトの接続ポリシー３５０に優先する接続ポリシー３５４のエントリ３５７では、端末２２から端末２１のサービスＩＤ１へのアクセスを毎日、午後１１時から、翌日午前６時まで拒否することを示している。さらに、エントリ３５８では、端末２６から端末２１のサービスＩＤ１へのアクセスを２００２年１月１日から２００２年１２月３１日まで拒否する。
【００５６】
このように、端末がサービスを提供している場合に、サービスを利用する端末が、サービスを提供する端末にアクセスする際に、本発明を適用可能である。
【００５７】
なお、図１に示す端末２１、から端末２８、認証サーバ３１、３２の各装置と、これら装置が備える各機能は、例えば、図１６に示すような、ＣＰＵ６１と、メモリ６２と、ハードディスク等の外部記憶装置６３と、ネットワークやＬＡＮ６９を介して他装置と通信を行うための通信装置６４と、キーボードやマウス等の入力装置６５と、モニタやプリンタ等の出力装置６６と、ＩＣカード等の可搬性を有する記憶媒体６８から情報を読み取る読取装置６７と、これらの各装置間のデータ送受を行うインタフェース６０とを備えた、電子計算機において、ＣＰＵ６１がメモリ６２上にロードされた所定のプログラムを実行することにより、実現できる。
【００５８】
これらのプログラムは、あらかじめ、上記電子計算機内のメモリ６２または外部記憶装置６３に格納されていても良いし、必要なときに、上記電子計算機が利用可能な、着脱可能な記憶媒体６８または通信媒体（ネットワークやＬＡＮ６９またはそれらの上を伝搬する搬送波）を介して、導入されてもよい。
【００５９】
なお、本実施例では、端末は、図１６に示されるような構成により実現できるとしているが、本発明はそれに限定されるものではない。図１に示す端末２１、から端末２８、の各機器は、サイト内ネットワークと接続することのできる通信装置を備えた機器であってもよい。例えば、ルータ、ＰＣ、携帯電話、ＰＤＡ、テレビ、冷蔵庫などの家電製品も、端末となりうる。
【００６０】
次に本実施例による通信システムの動作について説明する。
【００６１】
本実施の形態におけるセキュア通信システムは、サイトＡ内の端末２が、サイトＡ内ネットワーク４１、サイト外ネットワーク４０、サイトＢ内ネットワーク４２を介して、サイトＢ内の端末２と、セキュア通信を行うシステムである。ここでは、端末２１が端末２２に対し、セキュア通信の要求を行い、セキュア通信を終えるまでの動作を示す。
【００６２】
まず、端末２１と、端末２２がセキュア通信を行う場合、端末２１と端末２２は、図２に示すフローに従い、公開鍵証明書５０９１と公開鍵証明書５０９２を交換する。
【００６３】
端末２１は、端末２２の公開鍵証明書５０９２の要求を端末２２に送信する（ステップ１０００）
端末２２は、端末２１から送られてきた公開鍵証明書５０９２の要求を受信する（ステップ１００２）
ステップ１００２で要求を受けた公開鍵証明書５０９２を保持している場合（ステップ１００４でYES）は、端末２２は、端末２２の公開鍵証明書５０９２と、端末２１の公開鍵証明書５０９１の要求を、端末２１に送信する（ステップ１００６）。
【００６４】
端末２１は、端末２２の公開鍵証明書５０９２と、端末２１の公開鍵証明書５０９１の要求を、端末２２から受信する（ステップ１００８）
ステップ１０１０で要求を受けた公開鍵証明書５０９１を保持している場合（ステップ１０１０でYES）は、端末２１は、端末２１の公開鍵証明書５０９１を、端末２２に送信する（ステップ１０１２）。
【００６５】
端末２２は、端末２１の公開鍵証明書５０９１を、端末２１から受信する（ステップ１０１４）
端末２２は、端末２１の公開鍵証明書５０９１を、受信したことを、端末２１に通知するために、端末２１の公開鍵証明書５０９１の受信通知を、端末２１に送信する（ステップ１０１６）。
【００６６】
端末２１は、端末２１の公開鍵証明書５０９１の受信通知を、端末２２より受信する（ステップ１０１８）。
【００６７】
上記ステップ１００４または、ステップ１０１０でNOの場合（公開鍵証明書を保持していない場合）は、図１７のステップ１３１６（Ａ）へ進み、セキュア通信を切断する処理を行う。ただし、図１７は端末２１から通信終了を要求する場合を示しており、ステップ１００４から進む場合は、端末２２が通信終了要求を出すので、端末２１と端末２２との動作が入れ替わる。
【００６８】
上記処理を行うことにより、端末２１と、端末２２は、公開鍵証明書５０９１と５０９２を交換する。
【００６９】
次に、端末２１と端末２２はそれぞれ、図３に示すフローに従い、所属するサイトの認証サーバ３１、３２に、通信先端末２２、２１との通信許可をもとめ、可否判定を受け取る。
【００７０】
図３は、端末２１が認証サーバ３１に通信許可を求める場合を示すが、端末２２が認証サーバ３２に通信許可をもらう場合も、同様の手順を行う。
【００７１】
端末２１は、認証サーバ３１に端末２２との通信許可を求めるために、通信元端末である端末２１の公開鍵証明書５０９１と通信先である端末２２の公開鍵証明書５０９２を認証サーバ３１に送信する（ステップ１１００、ステップ１１０４）
認証サーバ３１は、公開鍵証明書５０９１と、公開鍵証明書５０９２を、受信する（ステップ１１０２、ステップ１１０６）
このとき、公開鍵証明書５０９２を送った後で、公開鍵証明書５０９１を送っても良い。あるいは、二つの公開鍵証明書を同時に送っても良い。
【００７２】
認証サーバ３１は、アクセス制御機能３０２１により、問い合わせを受けたセキュア通信が、接続ポリシー３０１で許可されているかどうかを判定する。具体的には、ステップ１１０２、ステップ１１０６で受信した公開鍵証明書５０９１から、通信元と通信先のデータを取り出す。
【００７３】
次に、設定する接続ポリシー（許可）３１２で許可されているかどうかを調べる。なお、本実施例では、設定する接続ポリシー（許可）３１２は、複数のエントリが存在する場合があり、その場合には、一行に一エントリを記載し、より下の行のエントリが、優先して適用される、としている。すなわち、エントリが複数ある場合には、それぞれのエントリの情報を、ポリシーの情報を保管するファイルの先頭から後へ（上から下へ）順に保存し、より後方に（下方に）保管されたエントリが、優先して適用される、とする。このため、一番下のエントリから順に、接続要求が接続ポリシーエントリに合致するか調べ、合致した時点で、接続可と判定する。もし、いずれかのポリシーに合致しない場合には、デフォルトのポリシー３１０により、通信拒否と判定する。（ステップ１１０８）。
【００７４】
なお、意図した通信許可判定１１０８が行えるようにあらかじめ、エントリの優先順位を決めておき、優先順位の低い順に、当該ファイルの先頭から後へ、エントリを保存する。
【００７５】
接続ポリシー３０で許可されていない場合は（ステップ１１１０でNO）、ステップ１１２０へ進む。
【００７６】
許可されている場合には（ステップ１１１０でYES）、端末２１から送られてきた、公開鍵証明書５０９１を検証する。公開鍵証明書５０９１の検証では、有効期限、署名、公開鍵証明書失効リストを検証する（ステップ１１１２）。
【００７７】
公開鍵証明書５０９１の検証１１１２が成功しなかった場合は（ステップ１１１４でNO）、ステップ１１２０へ進む。
【００７８】
公開鍵証明書５０９１の検証１１１２が成功した場合は（ステップ１１１４でYES）、公開鍵証明書５０９２を検証する。公開鍵証明書５０９２の検証では、有効期限、署名、公開鍵証明書失効リストを検証する（ステップ１１１６）。
【００７９】
通信先すなわち端末２２の公開鍵証明書５０９２の検証１１１６が成功しなかった場合は（ステップ１１１８でNO）、ステップ１１２０へ進む。
【００８０】
通信先すなわち端末２２の公開鍵証明書５０９２の検証１１１６が成功した場合は（ステップ１１１８でYES）、認証サーバ３１の署名を付与した、接続許可通知を端末２１に対して送信する（ステップ１１２２）。
【００８１】
ステップ１１２０では、認証サーバ３１の署名を付与した、接続不可通知を端末２１に対して送信する。
【００８２】
端末２１はステップ１１２０あるいは１１２２で送信された、接続不可通知あるいは接続許可通知を受信し、通知に付与された認証サーバ３１の署名を検証することにより、通知が確かに認証サーバ３１から送付されたことを確認する（ステップ１１２４）。
【００８３】
端末２１は、接続許可通知を受け取った場合は（ステップ１１２６でYES）、図４の（Ｃ）へ処理を進める。
【００８４】
端末２１は、接続不可通知を受け取った場合は（ステップ１１２６でNO）、セキュア通信を切断するために、図１７のステップ１３１６（Ａ）に進む。
【００８５】
それぞれが所属するサイトの認証サーバ３１、３２より通信可の判定を受け取った端末２２、２１は、図４に示すように、互いに、ＩＤに電子署名を添付し、電子署名を添付したＩＤを交換し、交換した電子署名を検証することで、通信相手を認証し、その後、鍵共有を行う。
【００８６】
まず、端末２１は端末２１のＩＤに対して、電子署名を生成し、ＩＤに生成した電子署名を添付して、端末２２に送信する（ステップ１２００）
端末２２は、電子署名を添付した端末２１のＩＤを端末２１から受信する（ステップ１２０２）
端末２２は、受信した電子署名をステップ１０１８で受信した端末２１の公開鍵証明書５０９１の公開鍵を用いて、検証する（ステップ１２０４）
電子署名の検証に成功した場合は（ステップ１２０６でYES）、端末２２のＩＤに対して、電子署名を生成し、ＩＤに生成した電子署名を添付して、端末２１に送信する（ステップ１２０８）。
【００８７】
端末２１は、電子署名を添付した端末２２のＩＤを端末２２から受信する（ステップ１２１０）
端末２１は、受信した電子署名をステップ１０１０で受信した端末２２の公開鍵証明書５０９２の公開鍵を用いて、検証する（ステップ１２１２）
端末２１は、電子署名の検証に成功した場合は（ステップ１２１４でYES）、暗号化通信を行うための複数の暗号化通信パラメータの候補を端末２２に送信する（ステップ１２１６）。
【００８８】
端末２２は、端末２１から暗号化通信パラメータの候補を受信する（ステップ１２１８）
端末２２は、受信した暗号化通信パラメータの候補の中から、１つ選択し、選択した暗号化通信パラメータを、端末２１に送信する（ステップ１２２０）。
【００８９】
端末２１は、端末２２から選択した暗号化通信パラメータを受信する（ステップ１２２２）
端末２１は、端末２２から選択した暗号化通信パラメータを受信した確認メッセージを端末２２に送信する（ステップ１２２４）
端末２２は、端末２１から選択した暗号化通信パラメータ受信の確認メッセージを端末２１から受信する（ステップ１２２６）。
【００９０】
ステップ１２０６またはステップ１２１４でNOの場合（電子署名の検証に失敗した場合）は、セキュア通信を切断するために、図１７のステップ１３１６に進む（Ａ）。ただし、図１７は端末２１から通信終了を要求する場合を示しており、ステップ１２０６から進む場合は、端末２２が通信終了要求を出すので、端末２１と端末２２との動作が入れ替わる。
【００９１】
以上の処理で、端末２１と端末２２は暗号化通信時に用いる暗号化通信パラメータを共有することができる。
【００９２】
次に端末２１は、暗号化通信用の端末２２と共通の鍵を暗号化通信パラメータを基に生成する（ステップ１２２８）。その後、暗号化通信のためのコネクションを確立する手続きＤへ進む。端末２２は、暗号化通信用の端末２１と共通の鍵を暗号化通信パラメータを基に生成する（ステップ１２３０）。その後、暗号化通信のためのコネクションを確立する手続きＥへ進む。以上で、通信相手の認証と鍵共有が完了する。
【００９３】
通信相手が認証できたら、通信コネクションを確立し、暗号化通信を行う。
【００９４】
図５は、暗号化通信を行うための、コネクションを確立し、暗号化通信を行い、暗号化通信終了時に、コネクションを切断するステップを示したシーケンス図である。
【００９５】
端末２１、端末２２にデータ転送許可要求を送信し（ステップ１３００）、
端末２２は、これを受信する（ステップ１３０２）。
【００９６】
端末２２は、端末２２のデータ転送許可と、端末２１へのデータ転送許可要求を、端末２１へ送信し（ステップ１３０４）、
端末２１は、これらを受信する（ステップ１３０６）。
【００９７】
端末２１は、端末２２のデータ転送許可を、端末２２へ送信し（ステップ１３０８）、
端末２２は、これを受信する（ステップ１３１０）。
【００９８】
上記処理により、端末２１と、端末２２は、お互いにデータ転送許可を出したので、コネクションが確立する（ステップ１３１２）。
【００９９】
コネクション確立後は、図４のステップ１２２０、ステップ１２２２で共有した、暗号化通信パラメータと、ステップ１２２８とステップ１２３０で生成した鍵を用いて、端末２１と、端末２２は、暗号化通信を行う（ステップ１３１４）。
【０１００】
暗号化通信が終了したら、図１７に示すシーケンスに従って、コネクションを切断する。
【０１０１】
暗号化通信を終える場合には、まず、端末２１は、端末２２との、通信終了要求を端末２２に送信し（ステップ１３１６）、
端末２２は、これを受信する（ステップ１３１８）。
【０１０２】
端末２２は、通信終了許可と、通信終了許可要求を端末２１へ送信し（ステップ１３２０）、
端末２１は、これらを受信する（ステップ１３２２）。
【０１０３】
端末２１は、通信終了許可を端末２２へ送信し（ステップ１３２４）、端末２２は、これを受信する（ステップ１３２６）。
【０１０４】
上記処理により、端末２１と、端末２２は、お互いに通信終了許可を受信したので、コネクション切断が完了する（ステップ１３２８）。
【０１０５】
次に接続ポリシー３０を設定する動作について説明する。
【０１０６】
図１１は、図１の接続ポリシー管理機能３０３１の手順を示す図である。
【０１０７】
まず、サイトＡの管理者は、サイトＡで、接続ポリシー（拒否）３１０あるいは、接続ポリシー（許可）３２０のどちらをデフォルトとして採用するか決めて設定する（ステップ３０００）。
【０１０８】
図６の接続ポリシーを選択した場合は、設定する接続ポリシー（許可）３１２に接続ポリシーのエントリ３１３を追加する。図７の接続ポリシーを選択した場合は、設定する接続ポリシー（拒否）３２２に接続ポリシーのエントリ３２３を追加する（ステップ３００２）。
【０１０９】
ステップ３００２は必要な設定接続ポリシーの数だけ、繰り返す（ステップ３００４）。
【０１１０】
以上が、接続ポリシー３０を設定するシーケンスである。
【０１１１】
端末がサービスを提供する場合の接続ポリシー３０を設定するには、図１１のステップ３０００で、デフォルトの接続ポリシー３５０を設定し、上記シーケンス同様、設定する接続ポリシー３５４の追加を繰り返せばよい。
【０１１２】
サイトＡ内では、認証サーバ３１が接続ポリシー３０を集中管理するので、サイトＡの管理者は、認証サーバ３１の接続ポリシー３０１を管理しておけばよい。変更が必要になった場合は、認証サーバ３１の接続ポリシー３０１を書き換えることにより、サイトＡ内のすべての端末２１、２３、２４、２５に、変更後の接続ポリシー３０１が、すぐに適用される。
【０１１３】
図１２に接続ポリシーの変更の手順を示す。
【０１１４】
まず、図６の接続ポリシーから、図７の接続ポリシー、あるいは、図７の接続ポリシーから、図６の接続ポリシーへ変更する場合は（ステップ３１００でYES）、現在認証サーバ３１で保持している接続ポリシーを一度すべて、削除する（ステップ３１０２）
その後、接続ポリシーの設定手順３０００から３００４を実行する（ステップ３１０４）。
【０１１５】
デフォルトの接続ポリシーを変更しない場合は（ステップ３１００でNO）、現在設定している接続ポリシーエントリで、不必要なものがあれば削除する（ステップ３１０６）
設定する接続ポリシーで、接続ポリシーエントリ３１３や３２３の項目に修正が必要なものがある場合は、修正する（ステップ３１０８）。
【０１１６】
設定する接続ポリシーのエントリの優先順位を決める（ステップ３１１０）。設定する接続ポリシーエントリが複数ある場合には、一行に一エントリを記載し、より下の行に記載したエントリが、より上の行に記載したエントリに優先して適用される。すなわち、エントリが複数ある場合には、それぞれのエントリの情報を、ポリシーの情報を保管するファイルの先頭から後へ（上から下へ）順に保存し、より後方に（下方に）保管されたエントリが、優先して適用される、とする。
【０１１７】
ステップ３１１０で接続ポリシーのエントリの順番を入れ替え、接続ポリシーエントリの優先順位を設定する。
【０１１８】
端末がサービスを提供する場合の図１０の接続ポリシーを変更するには、図１２のステップを同様に行う。
【０１１９】
なお、本実施例では、サイトＡ内の端末とサイトＢ内の端末間のセキュア通信について説明しているが、例えば、サイトＡ内の端末２３と端末２４がお互いに相手を認証することにより、サイト内のセキュア通信を行うこともできる。
【０１２０】
また、本実施例では、認証局が端末２１、２２に対して公開鍵証明書を発行するとしているが、例えば、認証局から、端末２１のユーザに対して、公開鍵証明書５０９１を発行してもよい。この場合は、端末２１は、端末２１を利用するユーザの公開鍵証明書５０９１を保管する。ユーザが、端末２１に保管された公開鍵証明書５０９１にアクセスする際、端末２１が、ユーザを認証することにより、正しいユーザが、正しい公開鍵証明書５０９１にアクセスすることができる。ユーザは、端末に保管された公開鍵証明書５０９１を用いて、端末２１と端末２２の間のセキュア通信を行う。
【０１２１】
さらには、認証局は、組織あるいはグループに対して1枚あるいは、複数枚の公開鍵証明書を発行してもよい。組織あるいは、グループのメンバは、公開鍵証明書を用いて、セキュア通信を行う。公開鍵証明書が複数枚発行されている場合は、端末を利用するユーザによって、利用する公開鍵証明書を切り替えて、セキュア通信を行うことができる。
【０１２２】
また、本実施例では、上記のように、公開鍵証明書５０９１は端末２１に保管されるとしているが、可搬性を有する記憶媒体に保管しても良い。これにより、図１３に示すように、記憶媒体を挿入した端末から、セキュア通信を行うことができる。
【０１２３】
図１３では、認証局が、ユーザ２０１に発行した公開鍵証明書５０９９は、ユーザ２０１が所有する可搬性を有する記憶媒体２１１に保管される。ユーザ２０１は記憶媒体２１１を端末２１に挿入することにより、端末２１を利用して、端末２２とセキュア通信を行うことができる。ユーザ２０１が、記憶媒体２１１を所有するため、公開鍵証明書５０９９と、ユーザ２０１との１対１関係ができる。
【０１２４】
同様に、認証局が、ユーザ２０２に発行した公開鍵証明書５０９１０は、ユーザ２０２が所有する記憶媒体２１２に保管される。ユーザ２０２は記憶媒体２１２を端末２１に挿入することにより、端末２１を利用して、端末２２とセキュア通信を行うことができる。上記のように、複数のユーザ２０１と、２０２が、一つの端末２１を利用することもできる。
【０１２５】
さらに、図７において、ユーザ２０１は、複数の公開鍵証明書を、記憶媒体２１１内に保有することができる。記憶媒体２１１を端末２１に挿入し、保管されている公開鍵証明書のうちの一つを用いて、端末２２とセキュア通信を行うこともできる。
【０１２６】
また、本実施例では、端末２１が、認証サーバ問い合せ機能２０３１を搭載しているが、例えば、サイトＡ内ネットワーク４１とサイトＡ外のネットワーク４０の間にルータを設置し、当該ルータは、端末２と同様の機能を保持するようにしてもよい。さらに、図１４に示すように、端末２１が、認証サーバ３１に接続可否を問い合わせた場合、端末２１とサイトＡのルータが接続可否通知を受け取ることもできる。
【０１２７】
端末２１は、端末２１と端末２２の公開鍵証明書を、認証サーバ３１に送信する（ステップ２０００）
認証サーバ３１は、端末２１と端末２２の公開鍵証明書を端末２１から受信する（ステップ２００２）
認証サーバ３１は、接続ポリシー３０１を参照し合致しているか調べ、端末２１と端末２２の公開鍵証明書を検証し、接続可否判定を行う（ステップ２００４）。
【０１２８】
認証サーバ３１は、接続可否判定を、端末２１とサイトＡのルータに送信する（ステップ２００６）
端末２１は、認証サーバ３１より、接続可否通知を受信する（ステップ２００８）
サイトＡのルータも認証サーバ３１より、接続可否通知を受信する（ステップ２０１０）
端末２１は、接続拒否の判定を受信した場合は、ステップ１３１６で通信の終了処理を行う。また、サイトＡのルータが、接続拒否の判定を受信したときに、サイトＡのルータが、強制的に通信の切断処理をおこなうこともできる。
【０１２９】
また、図１５に示すように、サイトＡのルータが、認証サーバ３１に接続可否を問い合わせることもできる。
【０１３０】
サイトＡのルータは、図２のシーケンスで証明書を載せたパケットがルータを通過する際、端末２１と端末２２の公開鍵証明書を取り出し、認証サーバ３１に送信する（ステップ２０００）
認証サーバ３１は、端末２１と端末２２の公開鍵証明書をサイトＡのルータから受信する（ステップ２００２）
認証サーバ３１は、接続ポリシー３０１を参照し合致しているか調べ、端末２１と端末２２の公開鍵証明書を検証し、接続可否判定を行う（ステップ２００４）。
【０１３１】
認証サーバ３１は、接続可否判定を、端末２１とサイトＡのルータに送信する（ステップ２００６）
端末２１は、認証サーバ３１より、接続可否通知を受信する（ステップ２００８）
サイトＡのルータも認証サーバ３１より、接続可否通知を受信する（ステップ２０１０）
端末２１は、接続拒否の判定を受信した場合は、ステップ１３１６で通信の終了処理を行う。また、サイトＡのルータが、接続拒否の判定を受信したときに、サイトＡのルータが、強制的に通信の切断処理をおこなうこともできる。
【０１３２】
このように、端末２１が仮に、不正に端末２２とセキュア通信しようとした場合にも、サイトＡのルータが強制的に通信の切断処理を行うことができる。
【図面の簡単な説明】
【０１３３】
【図１】本発明の一実施形態におけるセキュア通信システムの構成を示す図である。
【図２】端末２１と端末２２が公開鍵証明書を交換する処理手順を示すフローチャートである。
【図３】端末２１が認証サーバ３１へ接続許可を問い合わせ、認証サーバ３１が端末２１に接続可否通知を返答する処理手順を示すフローチャートである。
【図４】端末２１と端末２１が電子署名を用いてお互いに相手を認証し、端末２１と端末２１が各々、暗号化通信用の鍵を生成する処理手順を示すフローチャートである。
【図５】端末２１と端末２１がコネクションを確立し、暗号化通信を行うまでの処理手順を示すフローチャートである。
【図６】認証サーバ３１、３２が保持する接続を許可する接続ポリシーのリストである。
【図７】認証サーバ３１、３２が保持する接続を拒否する接続ポリシーのリストである。
【図８】図６、図７に示す接続ポリシーを構成する通信元と通信先の例を示す表である。
【図９】端末２１が提供するサービスＩＤとサービスメニューの対応関係を示す表である。
【図１０】認証サーバ３１が保持する端末２１の接続ポリシーのリストである。
【図１１】認証サーバ３１、３２の接続ポリシー管理機能における接続ポリシーの設定手順を示したフローチャートである。
【図１２】認証サーバ３１、３２の接続ポリシー管理機能における接続ポリシーの変更手順を示したフローチャートである。
【図１３】公開鍵証明書をユーザが所有する可搬性を有する記憶媒体に保管し、記憶媒体を端末に挿入することにより、端末で公開鍵証明書を利用する場合を示す図である。
【図１４】端末２１から認証サーバ３１に問い合わせを行い、端末２１とサイトＡのルータに通信可否判定を返すフローチャートである。
【図１５】サイトＡのルータから認証サーバ３１に問い合わせを行い、端末２１とサイトＡのルータに通信可否判定を返すフローチャートである。
【図１６】端末２１〜２８、認証サーバ３１、３２の各々のハードウェア構成例を示す図である。
【図１７】端末２１と端末２１がコネクションを切断する処理手順を示すフローチャートである。
【符号の説明】
【０１３４】
２１〜２８…端末、２０１、２０２…ユーザ、２１１、２１２…可搬性を有する記憶媒体、３１、３２…認証サーバ、３０…インタフェース、３１…ＣＰＵ、３２…メモリ、３３…外部記憶装置、３４…通信装置、３５…入力装置、３６…出力装置、３７…読取装置、３８…可搬性を有する記憶媒体、４０…サイト外ネットワーク、４１…サイトＡ内ネットワーク、４２…サイトＢ内ネットワーク、５０９１〜５０９１０…公開鍵証明書。
【図１】
2005217679.tif 000003
【図２】
2005217679.tif 000004
【図３】
2005217679.tif 000005
【図４】
2005217679.tif 000006
【図５】
2005217679.tif 000007
【図６】
2005217679.tif 000008
【図７】
2005217679.tif 000009
【図８】
2005217679.tif 000010
【図９】
2005217679.tif 000011
【図１０】
2005217679.tif 000012
【図１１】
2005217679.tif 000013
【図１２】
2005217679.tif 000014
【図１３】
2005217679.tif 000015
【図１４】
2005217679.tif 000016
【図１５】
2005217679.tif 000017
【図１６】
2005217679.tif 000018
【図１７】
2005217679.tif 000019