通信システムおよび安全性保証装置
【課題】 通信相手がセキュリティ対策を施していることを保証することができる通信システムおよび安全性保証装置を提供する。
【解決手段】 サーバ3は、ACの発行に必要な情報104をセキュリティ保証局2へ送信する。セキュリティ保証局2は、ACの発行に必要な情報104に基づいてサーバ3の通信上の安全性を検証する。セキュリティ保証局2は、サーバ3の通信上の安全性を確認した場合に、サーバ3の通信上の安全性を証明するAC105を発行し、サーバ3へ送信する。サーバ3はAC105を受信し、クライアント4からの接続要求に応じてAC105をクライアント4へ送信する。クライアント4は、AC105を受信し、AC105に基づいて、サーバ3の通信上の安全性を検証する。
【解決手段】 サーバ3は、ACの発行に必要な情報104をセキュリティ保証局2へ送信する。セキュリティ保証局2は、ACの発行に必要な情報104に基づいてサーバ3の通信上の安全性を検証する。セキュリティ保証局2は、サーバ3の通信上の安全性を確認した場合に、サーバ3の通信上の安全性を証明するAC105を発行し、サーバ3へ送信する。サーバ3はAC105を受信し、クライアント4からの接続要求に応じてAC105をクライアント4へ送信する。クライアント4は、AC105を受信し、AC105に基づいて、サーバ3の通信上の安全性を検証する。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、通信相手の安全レベルを保証することを図った通信システムおよび安全性保証装置に関する。
【背景技術】
【0002】
PKI(Public Key Infrastructure:公開鍵基盤)は、既存のインターネットにおける通信相手を認証するための基盤技術であり(例えば非特許文献1参照)、社会的に信頼されているCA(Certificate Authority:認証局)が、公開鍵と秘密鍵のペアを作成したホストの公開鍵に対して「確かに該当ホストが公開鍵を作成した」ことを保証する技術である。PKIにおいては、通信相手(ここではサーバと呼ぶ)が生成した公開鍵と秘密鍵のペアのうち公開鍵に対して、社会的に信頼されているCAが、自身の秘密鍵を使ってデジタル署名(証明書の発行)を施した公開鍵証明書(PKC:Public Key Certificate)を発行している。通信の受け側(ここではクライアントと呼ぶ)は、通信相手から送られてきたPKCを確認するために、CAの公開鍵を用いてPKCのデジタル署名を検証し、通信相手の本人性(識別性)を認証している。
【0003】
CAは、公開鍵と秘密鍵のペアを作成したサーバから公開鍵を受け取り、サーバの身元をオフラインで確認した後に、その公開鍵を含む証明書を発行する。ここで発行とは、サーバの公開鍵とその付随情報を含めた情報の全体に、CA自身の秘密鍵でデジタル署名を施す処理である。代表的な証明書として、X.509証明書がある(例えば非特許文献2〜4参照)。
【0004】
この証明書には、本人性の証明用のPKCと、PKCにリンク付けされた属性証明用の属性証明書(AC:Attribute Certificate)とがある(図22参照)。PKCやACの拡張領域には、公開鍵所有者に付随する情報や証明書の利用目的などの属性情報を付加することが可能である。ただし、頻繁に属性が更新される場合には、PKCの更新コストが問題になるため、ACを利用することになる。PKCは、信頼されるCAに発行・管理されるが、ACはローカルな属性認証局(AA:Attribute Authority)で発行・管理してもよい。
【0005】
図23は、CAおよびAAによるPKCおよびACの発行・指定関係を示している。認証局(CA)1は、端末(EE)7からの要求に応じて、端末7の公開鍵証明書(PKC)100を発行する。属性認証局(AA)6は、端末7の公開鍵証明書100にリンク付けされた属性証明書(AC)101を発行する。
【0006】
PKCの署名が正しく、有効期限内であっても、何らかの理由により、PKCを無効化しなければならないことがある。無効化するPKCは失効証明書リスト(CRL: Certificate Revocation List)に記録される。このフォーマットを図24に示す。
【0007】
通信システムにおけるウィルス等の攻撃に対して、通信システムの安全性を向上させるためのシステムとして、侵入検知システム(IDS:Intrusion Detection System)およびウィルス検知システム(VDS:Virus Detection System)がある。IDSは、ネットワーク上を流れるパケットやホスト上のログファイルを監視して、攻撃パターンファイルと一致するパケットやログファイルを検知するとアラームを発するシステムである。図25は、ネットワーク上のパケットを監視して、不正な行為を監視するネットワーク型IDSのモデルを示している(例えば非特許文献5参照)。
【0008】
図において、IDS8はネットワーク11aおよび11b間を流れるパケット200を監視する。IDS8において、パケット取得部81は、パケット200を取得し、攻撃検査部82へ出力する。攻撃検査部82は、攻撃パターンファイル300に記録されている攻撃パターンに基づいて、取得されたパケットが攻撃によるものであるかどうか判断し、攻撃によるものであると判断した場合には、ログ301に記録すると共に、アラームを発する等の処理を行う。
【0009】
一方、VDSは、ホスト上のファイルもしくはネットワーク上で送受信されるファイルの中に、コンピュータウイルスのパターンファイルと一致するコードを検知するとアラームを出力するシステムである(例えば非特許文献6参照)。一般にVDSは、クライアントホストやサーバ、ネットワークGW(ゲートウェイ)に設置される。
【非特許文献1】カーライル・アダムス、スティーブ・ロイド著,鈴木優一訳,「PKI 公開鍵インフラストラクチャの概念、標準、展開」,ピアソン・エデュケーション,2000年7月。
【非特許文献2】「Information Technology - Open Systems Interconnection - The Directory Authentication Framework.」,ITU-T Recommendation X.509,June 1997,(equivalent to ISO/IEC 9594-8,1997)
【非特許文献3】「Internet X.509 Public Key Infrastructure Certificate and CRL Profile」,IETF,RFC2459,1999.
【非特許文献4】「An Internet Attribute Certificate Profile for Authorization」,IETF,RFC3281,2002
【非特許文献5】武田圭史、磯崎宏,「ネットワーク侵入検知」,ソフトバンク パブリッシング,2000年6月
【非特許文献6】アトミックドロップ,「まるごと図解 最新 コンピュータウイルスがわかる」,技術評論社,2000年10月
【発明の開示】
【発明が解決しようとする課題】
【0010】
しかし、従来の通信システムにおいては、通信相手の本人性を認証することはできるものの、その通信の安全性レベルを保証するものではなかった。従って、通信相手のサーバが悪意のサーバや、セキュリティ対策を図っていないサーバであった場合、クライアント側が攻撃されることもあるという問題点があった。
【0011】
本発明は、上述した問題点に鑑みてなされたものであって、通信相手がセキュリティ対策を施していることを保証することができる通信システムおよび安全性保証装置を提供することを目的とする。
【課題を解決するための手段】
【0012】
本発明は、上記の課題を解決するためになされたもので、通信元装置と、該通信元装置と通信を行う通信相手装置と、前記通信相手装置の通信上の安全性を保証する安全性保証装置とを具備する通信システムであって、前記通信相手装置は、自身の通信上の安全性を通知するための通知情報を前記安全性保証装置へ送信し、前記安全性保証装置は、前記通知情報を受信し、該通知情報に基づいて前記通信相手装置の通信上の安全性を検証し、該通信上の安全性を確認した場合に、該通信上の安全性を証明する安全性証明情報を生成して前記通信相手装置へ送信し、前記通信相手装置は、前記安全性証明情報を受信し、前記通信元装置からの接続要求に応じて前記安全性証明情報を前記通信元装置へ送信し、前記通信元装置は、前記通信相手装置に対する接続要求の後、前記通信相手装置から前記安全性証明情報を受信し、該安全性証明情報に基づいて前記通信相手装置の通信上の安全性を検証することを特徴とする通信システムである。
【0013】
本発明は、通信元装置と、該通信元装置と通信を行う通信相手装置と、前記通信相手装置の通信上の安全性を保証する安全性保証装置とを具備する通信システムであって、前記通信相手装置は、自身の通信上の安全性を証明する安全性証明情報を前記安全性保証装置へ送信し、前記安全性保証装置は、前記安全性証明情報を受信し、該安全性証明情報に対して署名情報を付加して、前記安全性証明情報を前記通信相手装置へ送信し、前記通信相手装置は、前記安全性証明情報を受信し、前記通信元装置からの接続要求に応じて、前記署名情報の付加された前記安全性証明情報を前記通信元装置へ送信し、前記通信元装置は、前記通信相手装置に対する接続要求の後、前記通信相手装置から前記安全性証明情報を受信し、該安全性証明情報、および該安全性証明情報に付加された前記署名情報に基づいて前記通信相手装置の通信上の安全性を検証することを特徴とする通信システムである。
【0014】
本発明は、通信元装置と、該通信元装置からの接続要求に応じて、該通信元装置と通信を行う通信相手装置と、前記通信相手装置の通信上の安全性を保証する安全性保証装置とを具備する通信システムにおける安全性保証装置であって、前記通信相手装置によって送信された、該通信相手装置の通信上の安全性を通知する通知情報を受信する受信手段と、前記通知情報に基づいて前記通信相手装置の通信上の安全性を検証する検証手段と、該検証手段によって前記通信相手装置の通信上の安全性が確認された場合に、該通信上の安全性を証明する安全性証明情報を生成する証明情報生成手段と、該安全性証明情報を前記通信相手装置へ送信する送信手段とを具備することを特徴とする安全性保証装置である。
【0015】
本発明は、通信元装置と、該通信元装置からの接続要求に応じて、該通信元装置と通信を行う通信相手装置と、前記通信相手装置の通信上の安全性を保証する安全性保証装置とを具備する通信システムにおける安全性保証装置であって、前記通信相手装置によって送信された、該通信相手装置の通信上の安全性を通知する安全性証明情報を受信する受信手段と、前記安全性証明情報に対して署名情報を付加する署名情報付加手段と、該署名情報が付加された前記安全性証明情報を前記通信相手装置へ送信する送信手段とを具備することを特徴とする安全性保証装置である。
【発明の効果】
【0016】
本発明によれば、安全性保証装置が通信相手装置の通信上の安全性を証明するようにしたので、通信相手がセキュリティ対策を施していることを保証することができるという効果が得られる。
【発明を実施するための最良の形態】
【0017】
以下、図面を参照し、本発明を実施するための最良の形態について説明する。図1は、本発明の一実施形態による通信システムの構成を示すブロック図である。この通信システムは、サーバ・クライアント通信におけるサーバの本人性の認証を行うと共に、その通信の安全性のレベル(セキュリティレベル)を保証するシステムである。図において、認証局(CA)1は既存の認証局であり、サーバ3からのPKC(公開鍵証明書)の発行要求に応じて、サーバ3の公開鍵についてのPKC102(識別性情報)を発行する。セキュリティ保証局(SCA)2(安全性保証装置)は、サーバ3のセキュリティレベルを保証するためのAC(属性証明書)105を発行する。このセキュリティ保証局2は、既存の認証局1によって認証され、自身の公開鍵についてのPKCを発行されており、社会的に信頼されている第三者的な立場の機関とする。
【0018】
サーバ3(通信相手装置)は本人性および安全性の検証の対象となるサーバであり、セキュリティ対策システムの一種であるIDS(侵入検知システム)32およびVDS(ウィルス検知システム)33を備えている。クライアント4(通信元装置)はサーバ3に接続してサービスを受けようとしている端末装置である。このクライアント4は、サーバ3に対して発行されたPKC102およびAC105に基づいて、サーバ3の本人性(識別性)およびセキュリティレベル(通信上の安全性)の検証を行う署名検証部41を備えている。なお、認証局1、セキュリティ保証局2、サーバ3、およびクライアント4は図示せぬインターネットを介して相互に接続されている。
【0019】
図2は、セキュリティ保証局2の構成を示すブロック図である。以下、図中の各構成について説明する。通信部21は、インターネット10を介してサーバ3、クライアント4、およびIDS・VDSベンダ5等の他の通信装置と情報の送受信を行う。IDS・VDSベンダからの情報取得部22は、通信部21を介してIDS・VDSベンダ5から最新のIDS/VDSのパターンファイルを取得し、記憶部28に格納する。IDS/VDSのパターンファイルには、IDSおよびVDSが検知すべき攻撃やウィルスのパターンが予め記録されている。
【0020】
サーバとの通信制御部23はサーバ3との通信を制御する。クライアントとの通信制御部24はクライアント4との通信を制御する。サーバ認証部25はサーバ3の本人性およびセキュリティレベルの認証を行う。サーバへのIDS・VDSパターンファイル適用部26は、サーバ3に仕掛ける擬似攻撃を生成するが、詳細については後述する。属性証明書発行部27は、サーバ認証部25によってサーバ3の本人性およびセキュリティレベルが確認された場合に、属性証明書(AC)を発行する。記憶部28は、サーバ3に対するACの発行に必要な情報や、自身の公開鍵・秘密鍵に関する情報、発行したAC等を記憶する。
【0021】
図3は、サーバ3の構成を示すブロック図である。以下、図中の各構成について説明する。通信部31は、インターネット10を介して認証局1、セキュリティ保証局2、およびクライアント4等の他の通信装置と情報の送受信を行う。クライアント通信制御部34はクライアント4との通信を制御する。クライアントからのセッション受付部35は、クライアント4からの接続要求があった場合に、クライアント4との通信にセッションを設定し、そのセッションを管理する。
【0022】
IDS/VDSの起動監視部36はpsコマンドやlsコマンドを用いてIDS32およびVDS33の起動を確認し、それらの起動状態に関する情報を取得するが、詳細については後述する。SCAとの通信制御部37はセキュリティ保証局2との通信を制御する。記憶部38は、自身の公開鍵・秘密鍵に関する情報や、認証局1によって発行されたPKC、セキュリティ保証局2によって発行されたAC、IDS/VDSの運用に関する情報(ログ、パターンファイル)等の情報を記憶する。
【0023】
次に、本実施形態による通信システムの動作について説明する。前提として、セキュリティ保証局2は自身の公開鍵と秘密鍵のペアを作成し、認証局1からPKCを発行されているものとする。また、セキュリティ保証局2はIDS・VDSベンダ5からIDS/VDSの最新のパターンファイルを取得しているものとする。サーバ3は自身の公開鍵と秘密鍵のペアを生成し(ステップS1)、生成した公開鍵の正当性を保証するデジタル署名を依頼するためのPKC発行要求情報を生成し、認証局1へ送信する(ステップS2)。このPKC発行要求情報には、サーバ3の公開鍵が含まれている。
【0024】
認証局1はPKC発行要求情報を受信し、サーバ3の身元の確認後、PKC発行要求情報に付加されたサーバ3の公開鍵を含むサーバ3の情報に対して、自身の秘密鍵によりデジタル署名を施した署名情報を含むPKC102を生成し、サーバ3へ送信する(ステップS3)。このPKC102はサーバ3の通信部31によって受信され、IDS32を介して記憶部38に格納される。一方、セキュリティ保証局2においてサーバとの通信制御部23は記憶部28から最新のIDS/VDSのパターンファイルを読み出し、通信部21を介して、IDS/VDSパターンファイル103としてサーバ3へ送信する(ステップS4)。
【0025】
サーバ3において通信部31はセキュリティ保証局2からIDS/VDSパターンファイル103を受信し、IDS32へ出力する。IDS32はこのIDS/VDSパターンファイル103を記憶部38に格納する。また、SCAとの通信制御部37は、認証局1によって発行されたPKC102にリンク付けされるACの発行を要求するためのAC発行要求情報を生成し、IDS32および通信部31を介してセキュリティ保証局2へ送信する(ステップS5)。このAC発行要求情報には、サーバ3のPKC102(識別性証明情報)と、ACの発行に必要な情報104(通知情報)とが含まれる。PKC102は、サーバ3がセキュリティ保証局2に対して自身の身元を証明するための情報であり、ACの発行に必要な情報104は、自身のIDS32およびVDS33に関する情報等、自身のセキュリティレベルをセキュリティ保証局2に通知するための情報である。ACの発行に必要な情報104はPKC102の拡張領域に格納されていてもよい。
【0026】
セキュリティ保証局2はサーバ3からAC発行要求情報を受信し、PKC102に基づいてサーバ3を認証すると共に、ACの発行に必要な情報104に基づいてサーバ3のセキュリティレベルの認証を行い、両方の認証に成功した場合に、PKC102に基づいてAC105を生成し、サーバ3へ送信する(ステップS6)。以下、ステップS6におけるセキュリティ保証局2の動作を詳述する。
【0027】
サーバとの通信制御部23は、通信部21を介してサーバ3からAC発行要求情報を受信し、サーバ認証部25へ出力する。サーバ認証部25は、AC発行要求情報に付加されたPKC102に基づいて、サーバ3の身元を検証する。具体的には、サーバ認証部25は、PKC102に付加されている、認証局1の秘密鍵によって暗号化されたデジタル署名を認証局1の公開鍵で復号化し、デジタル署名の復号化によって得られた公開鍵等のデータと、PKC102に付加されている公開鍵等の非暗号化データとを比較し、両者が一致した場合に、サーバ3の身元の認証に成功したとする。
【0028】
また、サーバ認証部25は、AC発行要求情報に付加されたACの発行に必要な情報104に基づいて、サーバ3のセキュリティレベルを検証する。サーバ認証部25は、ACの発行に必要な情報104に含まれる情報から、サーバ3がセキュリティ対策を施しているかどうか知ることができ、さらに、後述する各手法により、サーバ3のセキュリティレベルをより正しく知ることができる。サーバ3の身元の認証およびセキュリティレベルの認証に成功した場合、サーバ認証部25は、属性証明書発行部27に対してACの発行を指示する。指示を受けた属性証明書発行部27は、PKC102に基づいてACを生成し、記憶部28に格納する。このACには、セキュリティ保証局2の秘密鍵によるデジタル書名が付与されており、また、拡張領域にはサーバ3のセキュリティレベルを証明する情報(安全性証明情報)が格納されている。属性証明書発行部27は、サーバ認証部25を介してACをサーバとの通信制御部23へ出力し、サーバとの通信制御部23は、通信部21を介して、このACをAC105としてサーバ3へ送信する(ステップS6)。
【0029】
続いて、クライアント4は、サーバ3との通信を開始するために、サーバ3に対する接続要求と、PKC102およびAC105の受信要求とを示す接続要求情報をサーバ3へ送信する(ステップS7)。サーバ3において通信部31は接続要求情報を受信し、IDS32を介してクライアントからのセッション受付部35へ出力する。クライアントからのセッション受付部35は、接続要求情報に基づいてクライアント4とのセッションを生成すると共に、PKC102およびAC105の送信をクライアント制御部34に指示する。指示を受けたクライアント制御部34は記憶部38からPKC102およびAC105を読み出し、IDS32を介して通信部31へ出力する。通信部31はPKC102およびAC105をクライアント4へ送信する(ステップS8)。
【0030】
クライアント4はサーバ3からPKC102およびAC105を受信し、自身が認証局1およびセキュリティ保証局2の公開鍵を所持している場合には、PKC102およびAC105のデジタル署名を検証する(ステップS9)。すなわち、クライアント4の署名検証部41は、PKC102に付加されている、認証局1の秘密鍵によって暗号化されたデジタル署名を認証局1の公開鍵で復号化し、デジタル署名の復号化によって得られた公開鍵等のデータと、PKC102に付加されている公開鍵等の非暗号化データとを比較し、両者が一致した場合に、サーバ3の身元の認証に成功したとする。
【0031】
また、署名検証部41は、AC105に付加されている、セキュリティ保証局2の秘密鍵によって暗号化されたデジタル署名をセキュリティ保証局2の公開鍵で復号化し、デジタル署名の復号化によって得られた公開鍵等のデータと、AC105に付加されている公開鍵等の非暗号化データとを比較し、両者が一致した場合に、サーバ3のセキュリティレベルの認証に成功したとする。
【0032】
一方、クライアント4が認証局1およびセキュリティ保証局2の少なくとも一方の公開鍵を予め所持していない場合には、以下のようになる。クライアント4が認証局1の公開鍵を予め所持していない場合には、クライアント4は、認証局1に対してPKCを要求する(ステップS10a)。PKCを要求された認証局1は、自身の公開鍵についてのPKC106をクライアント4へ送信する(ステップS11a)。クライアント4はPKC106を受信し、署名検証部41は、PKC106を用いてPKC102のデジタル署名を検証する。
【0033】
また、クライアント4がセキュリティ保証局2の公開鍵を予め所持していない場合には、クライアント4は、セキュリティ保証局2に対してPKCを要求する(ステップS10b)。PKCを要求されたセキュリティ保証局2は、自身の公開鍵についてのPKC107をクライアント4へ送信する(ステップS11b)。クライアント4はPKC107を受信し、署名検証部41は、PKC107を用いてAC105のデジタル署名を検証する。
【0034】
上記の検証の結果、サーバ3のPKC102およびAC105のデジタル署名の有効性が確認できた場合、サーバ3およびクライアント4は以後の通信を開始する。また、サーバ3のIDS32およびVDS33は、サーバ3側の通信を監視する(ステップS12)。PKC102およびAC105のデジタル署名の有効性が確認できた場合には、クライアント4は、AC105に関する概要情報(図4(a)参照)や詳細情報(図4(b)参照)を図示せぬ表示部に表示する。これにより、ユーザはサーバ3のセキュリティレベルを視覚的に確認することができる。また、図4(a)に示されるように、その表示に基づいて、ユーザに対して通信の開始の可否を選択させるようにしてもよい。
【0035】
次に、セキュリティ保証局2によるサーバ3のセキュリティレベルの認証について説明する。セキュリティ保証局2によって発行されるAC105の拡張フィールドには、セキュリティを保証する以下の情報のうちいくつかが付加される。ただし、これは、サーバ3が厳密な情報を提供する場合である。
・証明書の発行先情報(サーバ3を特定する情報)
・証明書の発行者情報(セキュリティ保証局2を特定する情報)
・証明書の発行日(証明書が生成された時を特定する情報)
・証明書の有効期限
・証明書を作成するためのアルゴリズムに関する諸情報
・IDSやVDSにより通信を監視している事実
・IDSやVDSに関するツール名もしくはツールID(IDSやVDSを特定する情報)
・IDSやVDSに関するバージョン番号(IDSやVDSを特定する情報)
・IDSやVDSの最新適用パターンファイルID(IDSやVDSを特定する情報)
・IDSやVDSの最新適用パターンファイル発行日(IDSやVDSを特定する情報)
・監視ポリシ
【0036】
サーバ3において複数のセキュリティツールが適用されている場合には、各セキュリティツールに関しての複数の情報が記載される。また、IDSやVDSで、通信をどのように監視するのかといったポリシ自体もしくはポリシIDが記載される。ここでポリシとは、IPスキャン攻撃は検知するが、ポートスキャン攻撃は検知しないといったパターンファイルの利用方法である。
【0037】
上記のような厳密な情報は、場合によってはセキュリティ情報の漏洩に繋がる場合もある。例えば、脆弱性を持つIDSやVDSを利用している場合や、パターンファイルの適用の遅れ等は、監視システムからの回避情報を侵入者に知らせることにもなる。よって、下記の情報のみがAC105の拡張フィールドに格納され、セキュリティ保証局2が保証するレベルのみをクライアント4に通知してもよい。
・証明書の発行先情報
・証明書の発行者情報
・証明書の発行日
・証明書の有効期限
・証明書を作成するためのアルゴリズムに関する諸情報
・IDSやVDSにより通信を監視している事実
【0038】
上記の情報は、セキュリティ保証局2が独自に決定するか、またはサーバ3からセキュリティ保証局2へ送信されるACの発行に必要な情報104に基づいてセキュリティ保証局2が生成する。例えば、証明書の発行先情報は、サーバ3から取得したPKC102に基づいてセキュリティ保証局2が生成する。また、証明書の発行者情報、証明書の発行日、証明書の有効期限、証明書を作成するためのアルゴリズムに関する諸情報もセキュリティ保証局2が決定する。その他、IDSやVDSにより通信を監視している事実、IDSやVDSに関するツール名もしくはツールID等の情報は、サーバ3から取得したACの発行に必要な情報104に基づいて、セキュリティ保証局2が生成する。
【0039】
セキュリティ保証局2は、サーバ3の本人性の認証に成功した場合であって、ACの発行に最低限必要な情報として、IDSやVDSにより通信を監視している事実を示す情報がACの発行に必要な情報104に格納されていた場合に、その情報に基づいて、サーバ3がセキュリティ対策を行っていることを信用し、AC105を生成してサーバ3へ送信してもよいが、サーバ3が悪意のサーバである可能性もあるため、サーバ3のセキュリティレベルをより確実に保証する手法が必要である。以下、このための手法について説明する。
【0040】
(1)インターネットサービスプロバイダ(ISP)等によるサーバシステムの管理
サーバ3や、サーバ3の処理を代行する後述の外部装置をISPやセキュリティ保証局2等の施設内で管理している環境では、サーバ3におけるIDSやVDSの動作状況をISPやセキュリティ保証局2の運用者が直接確認する。
【0041】
(2)サーバシステム自体の耐タンパ性の利用
ISPやセキュリティ保証局2が、サーバ3の処理を代行する後述するような外部装置を提供する場合に、その装置の耐タンパ性(不正アクセス・不正改竄防止機能)を担保にする。例えば、サーバ3の処理を代行する外部装置には、その装置が開封されただけで、その装置の動作を規定するソフトウェアが記録されているメモリおよびディスクや、その装置の動作を実現する回路自体等が物理的に壊れて、使用不能となってしまう仕組みを設ける。これにより、外部装置の内部構成を保護し、偽造を防ぐことができる。
【0042】
また、SSH通信による両方向の認証を利用して、サーバ3の処理を代行する外部装置またはサーバ3自体に、ISPやセキュリティ保証局2からしかIDSやVDSを遠隔操作することができない仕組みを設ける。以下、この場合について詳述する。SSHによる両方向の認証には、公開鍵暗号認証方式およびパスワード認証方式の2種類がある。以下、一般に用いられている「発信元」「着信元」モデルについて説明する。
【0043】
公開鍵暗号認証方式においては、発信元は自身の持つ秘密鍵によって署名した電子署名データを着信先に送信する。着信先は、発信元の公開鍵により電子署名データを復号化し、その電子署名の正当性を検証する。検証には、既存の認証局が発行したPKCを利用する。セキュリティ保証局2とサーバ3との間の両方向でお互いにPKCを交換し合うことにより、お互いを認証し合うことができる。一方、パスワード認証方式においては、予め発信元と着信先の両者で取り決めておいたパスワードを送受信することにより、認証を行う。これは、広く一般で利用されている方式であるが、SSH通信の場合、このパスワードは暗号によって保護されて送受信される。この場合、セキュリティ保証局2とサーバ3との間で予めパスワードを取り決めておく。なお、通信セッションの開始はセキュリティ保証局2およびサーバ3のどちらからでもよい。
【0044】
上記の認証の後、セキュリティ保証局2とサーバ3は暗号通信(例えば秘密鍵暗号方式)を行う。この暗号通信において、セキュリティ保証局2は、サーバ3の各部を制御し、操作するための操作情報をサーバ3へ送信してサーバ3を遠隔操作する。サーバ3は、操作情報に基づいて、IDS32およびVDS33に関する情報を生成し、セキュリティ保証局2へ送信する。セキュリティ保証局2は、その情報を受信し、ACの発行に必要な情報104の代わりに用いて、サーバ3のセキュリティレベルの検証を行う。
【0045】
また、上記の動作は、セキュリティ保証局2がサーバ3を遠隔操作するのではなく、サーバ3が主体的に動作することにより行ってもよい。すなわち、サーバ3はセキュリティ保証局2との両方向の認証後、IDS32およびVDS33に関する情報を生成し、セキュリティ保証局2へ送信する。セキュリティ保証局2は、その情報を受信し、ACの発行に必要な情報104の代わりに用いて、サーバ3のセキュリティレベルの検証を行う。
【0046】
(3)サーバ側での監視処理の起動確認
サーバ3上にIDS32やVDS33の状態を確認する専用の機能を予め用意する。Linux OSの場合には、「ps」コマンドにより、起動プロセスの情報を得る機能がある。サーバ3上でpsコマンドを実行することにより得られた情報の中から、IDSプロセス(またはVDSプロセス)の名前、IDSプロセス(またはVDSプロセス)のサイズを取得して、それらが正しい情報であれば(サーバ3がセキュリティ保証局2へ通知した情報と同じであれば)、起動していると判断する。具体的なコマンドは以下の通りである。
> ps -ef | grep プロセス名
【0047】
また、適用されているパターンファイルが最新のものであることを確認するために、サーバ3上で「ls」 コマンドを実行することにより得られた情報の中から、パターンファイルの名前、パターンファイルのサイズ、パターンファイルの日付(更新日)を取得して、最新のパターンファイルを適用したことが分かる情報を得る。具体的なコマンドは以下の通りである。
> ls -l ディレクトリ名/ファイル名
【0048】
サーバ3は、上記の2つのコマンドを実行することにより取得した、IDS32またはVDS33の状態を示す状態情報をまとめてセキュリティ保証局2へ送信する。ただし、このとき悪意のサーバは、情報を偽装する恐れがある。これを防止するために、上記の2つの情報収集処理と、これをセキュリティ保証局2に送信する処理を一つのプログラムとして作成しておき、このプログラムに対してソフトウェアの難読化を実施して、実行モジュールの改竄を防止する。
【0049】
難読化とは、整然と書かれているプログラムの構造を変形させることにより、実行結果は変わらないものの、その解析を困難にする技術である。具体的には、
・実行に影響を与えない不要なコードを追加する。
・命令コードを別の等価なコードに置き換える。
・一つの計算を複数の計算に分割する。
・一つの機能を持ったモジュール(関数、サブルーチン)を複数のモジュールに分割する。
・同一の処理を行うモジュールを複数用意して冗長化する。
等の操作をそのプログラムに対して行う。難読化のタイミングとしては二種類あり、一つは、ソースコードを難読化してからコンパイルして実行コードを得るというものであり、もう一つは、ソースコードをコンパイルしてから難読化して実行コードを得るというものである。
【0050】
上記の起動確認を行う場合、サーバ3のIDS/VDSの起動監視部36は、psコマンドまたはlsコマンドに相当する処理を実行し、IDS32またはVDS33(あるいは両方)について、上記の起動プロセスまたはパターンファイルについての状態情報を生成し、IDS32を介して通信部31へ出力する。通信部31は状態情報をセキュリティ保証局2へ送信する。
【0051】
セキュリティ保証局2の通信部21は状態情報を受信し、サーバとの通信制御部23を介してサーバ認証部25へ出力する。サーバ認証部25は、サーバ3のセキュリティレベルを以下のように認証する。サーバ認証部25は、サーバ3から受信されたACの発行に必要な情報104と状態情報とを比較し、状態情報が示すIDSプロセスの名前、IDSプロセスのサイズ、パターンファイルの名前、パターンファイルのサイズ、およびパターンファイルの日付が、ACの発行に必要な情報104に含まれるそれらの内容と一致するかどうか検証する。
【0052】
状態情報の内容がACの発行に必要な情報104に含まれる情報の内容と一致した場合、サーバ認証部25はサーバ3のセキュリティレベルを確認することができたとし、認証を終了する。これにより、セキュリティ保証局2は、ACの発行に必要な情報104としてサーバ3から通知された情報が、改竄できない実行モジュールに基づいて得た状態情報の内容と一致する正しい情報であることを知ることができ、サーバ3のセキュリティレベルをより確実に確認および保証することができる。なお、上記の場合、サーバ3がセキュリティ保証局2へ送信するACの発行に必要な情報104には、IDS32またはVDS33の状態情報が含まれている必要がある。
【0053】
(3)パターンファイルの適用の外部からの確認
セキュリティ保証局2が、サーバ3に対して擬似攻撃を仕掛け、サーバ3のIDS32またはVDS33によって出力されたログを取得し、そのログに基づいて、サーバ3が最新のパターンファイルを適用しているかどうか確認する。この場合、サーバへのIDS・VDSパターンファイル適用部26は記憶部28から最新のパターンファイル(パターン情報)を読み出し、更新された攻撃パターン(シグネチャ)を認識する。更新された攻撃パターンの認識において、サーバへのIDS・VDSパターンファイル適用部26は記憶部28から最新のパターンファイルおよびその一つ前のバージョンのパターンファイルを読み出し、両者の内容を比較し、最新のパターンファイルのみに含まれるパターンを、更新された攻撃パターンとして認識してもよい。
【0054】
続いて、サーバへのIDS・VDSパターンファイル適用部26は、更新された攻撃パターンに基づいた攻撃パケットを連続的に生成し、サーバ認証部25を介してサーバとの通信制御部23へ出力する。サーバとの通信制御部23は攻撃パケットを連続的にサーバ3へ送信する。サーバ3の通信部31は攻撃パケットを受信し、IDS32へ出力する。IDS32は記憶部38から最新のパターンファイルを読み出し、そのパターンファイルに基づいてパケットを監視し、最新の攻撃パターンと一致するパケットを検知した場合には、その攻撃パターン名(シグネチャ名)、送信元IP、時刻情報等をログ(攻撃検知情報)に記録する。
【0055】
IDS32は所定のタイミングでログを読み出し、通信部31へ出力する。通信部31はログをセキュリティ保証局2へ送信する。セキュリティ保証局2の通信部21はログを受信し、サーバとの通信制御部23を介してサーバ認証部25へ出力する。サーバ認証部25は、更新された攻撃パターンがログに記録されているかどうか検証し、記録されていた場合には、サーバ3のセキュリティレベルを確認することができたとし、認証を終了する。これにより、セキュリティ保証局2は、サーバ3が最新のパターンファイルに基づいたセキュリティ対策を行っているかどうか確認することができ、サーバ3のセキュリティレベルをより確実に確認および保証することができる。
【0056】
なお、セキュリティ保証局2が、ウィルスに関しての最新のパターンファイルに基づいて、ウィルスに感染した攻撃パケットを生成し、サーバ3へ送信してもよい。この場合、サーバ3においては、VDS33が、最新のパターンファイルに基づいて、ウィルスによるパケットを検出し、ログに記録する。セキュリティ保証局2は、上記と同様にしてこのログを取得し、最新のパターンファイルおよびログに基づいて、サーバ3のセキュリティレベルを認証する。
【0057】
次に、PKCおよびACの発行処理の他の形態について説明する。既存の認証局1がセキュリティ保証局2の役割を担うこともでき、その場合には、PKCとACとの両方を認証局1が発行する。逆に、既存の認証局1の役割をセキュリティ保証局2が代行することもでき、その場合には、PKCとACとの両方をセキュリティ保証局2が発行する。また、既存の認証局1はPKCを発行し、IDS/VDSベンダーがACを発行する場合も考えられる。
【0058】
次に、IDSやVDSとそのパターンファイルの管理および更新の形態ついて説明する。IDSやVDSの選定からパターンファイルの適用等の運用・管理に至るまで、サーバ管理者が独自に行ってもよいし、IDSやVDSの選定はサーバ管理者が行い、そのパターンファイルの適用に関しては、セキュリティ保証局2もしくはIDSやVDSを提供するベンダーが代行してもよい。あるいは、IDSやVDSの選定からパターンファイルの適用までセキュリティ保証局2もしくは、IDSやVDSを提供するベンダーが代行してもよい。この場合には、セキュリティ保証局2やベンダーは、IDSやVDSが設定されたネットワーク機器(ハードウェアのゲートウェイ等)をサーバ管理者に付与して、サーバ管理者はそれを設置するのみの作業となる。
【0059】
次に、サーバ3が行う各処理の代行について説明する。一般に、サーバを構築するときには、サーバ自体を簡易な構成にすること、余計な処理負荷を掛けないことが望まれている。そこで、
1)公開鍵と秘密鍵の生成処理
2)PKCの発行依頼と発行された証明書の管理
3)IDS/VDSのパターンファイルの更新
4)セキュリティ保証局2に対するACの発行依頼と、発行された証明書の管理
5)IDSやVDSによる通信の監視
6)クライアント4へのPKCとACの提示
の各種処理を、外部装置が代行してもよい。図1においては、サーバ3が上記の1)から6)の全ての処理を実行するとしているが、サーバ3の処理負荷を軽減するために、プロキシ装置、RouterやFirewall等のネットワークゲートウェイ(N−GW)、ホームゲートウェイ(H−GW)等の装置に、1)から6)のいくつか、もしくは全ての処理を代行させてもよい。
【0060】
次に、サーバ3がクライアント4に対してPKC102およびAC105を送信する際に、この動作を行う悪意のサーバを排除する方法について説明する。サーバ3はクライアント4から接続要求を受けるとPKC102およびAC105をクライアント4へ送信する。このとき、悪意のサーバはIDSやVDSを停止しているにも関わらず、AC105を送信することが考えられる。そこで、クライアント4からの接続要求を受けたサーバ3は、psコマンドやlsコマンドを実行して、IDSやVDSが実行されていることや最新のパターンファイルの適用を確認することができた場合にのみAC105をクライアント4へ送信する。psコマンドやlsコマンドによるIDSやVDSの起動確認処理とクライアント4へのAC105の提示処理とを一体化ソフトウェアとして1つのプログラムにまとめておき、この一体化ソフトウェアに対して難読化を実施することにより、悪意の改竄を防止することができる。
【0061】
次に、証明書の無効化処理について説明する。IDSやVDSに関する脆弱性情報が公開された場合や、新たなパターンファイルが出た場合には、以前の状態で発行されたACを無効化しなければならない。無効化のためには、図8のようなCRLを用いることになる。この場合、認証局1やセキュリティ保証局2は、発行したPKCやACに関するCRLを管理しておき、クライアント4から有効性の問い合わせがあったときに回答することになる。
【0062】
なお、クライアント4の署名検証部41が、サーバ3から送信されたPKC102およびAC105に基づいて、サーバ3の本人性およびセキュリティレベルの認証を行う際に、PKC102およびAC105の内容に応じて、サーバ3との通信の受け入れの可否を自動的に判断するようにしてもよい。
【0063】
上述した本実施形態においては、サーバ3がセキュリティ対策システムとしてIDS32およびVDS33を備えているが、Firewallあるいは検疫システムをセキュリティ対策システムとして備えていてもよい。Firewallは、ネットワークや端末の接続点において、許可されていないアクセスを棄却する装置であり、主に、外部ネットワークから内部ネットワークへのアクセスを制限することによって攻撃を防ぐものである。また、検疫システムは、OSやアプリケーションのバージョンおよびパッチの状態を確認して最新の状態を確保するものである。
【0064】
サーバ3がACの発行に必要な情報104をセキュリティ保証局2へ送信する際には、自身が有するOSやアプリケーションのバージョン、パッチの状態、およびPortの設定等を確認し、ACの発行に必要な情報104の中にこれらの情報を格納してセキュリティ保証局2へ送信するようにしてもよい。セキュリティ保証局2は、サーバ3のOSやアプリケーションについての上記の情報に基づいて、サーバ3のセキュリティレベルを検証してもよい。
【0065】
本実施形態においては、既存のPKIを利用して、セキュリティ保証局2がサーバ3のセキュリティレベルと共に本人性の検証を行っているが、サーバ3のセキュリティレベルの検証を行う上ではPKIは必須ではない。したがって、認証局1が設けられていなくてもよく、セキュリティ保証局2とサーバ3との間でPKCの送受信が行われなくてもよい。さらに、本実施形態においては、セキュリティ保証局2が、サーバ3のセキュリティレベルを証明する情報をAC105の拡張領域に格納してサーバ3へ送信しているが、これに限定されず、サーバ3のセキュリティレベルを証明する情報を含む独立したセキュリティ証明書として送信してもよい。また、ACの代わりにPKIの拡張領域に上記の情報を格納してもよく、SPKI(例えば文献「ITU-T,"SPKI Certificate Theory",IETF,RFC2693,1999」参照)において定義される形式の証明書に上記の情報を格納してもよい。
【0066】
次に、本実施形態の変形例について説明する。図5は、本変形例に係る通信システムの構成を示すブロック図である。図5においては認証局1の図示およびPKIに基づいた本人性の認証の図示は省略されている。本変形例においても、本人性の認証を行ってもよいし、行わなくてもよい。サーバ3内に設けられた内部監査モジュール39は、セキュリティ保証局2から外部監査(最新の攻撃パターンに基づいた擬似攻撃)を受けた場合に、IDS32およびVDS33の状態あるいはOS/アプリケーションのバージョン等を確認するソフトウェアまたはハードウェアである。本変形例においては、サーバ3のセキュリティレベルを証明する情報がセキュリティ証明書109に含まれているとする。
【0067】
また、本変形例においては、セキュリティ証明書109の発行はサーバ3が行い、セキュリティ保証局2は、サーバ3が発行したセキュリティ証明書109に対して署名を施す。サーバ3によって発行されたサーバ3自身のセキュリティ証明書109は仮の状態であり、セキュリティ保証局2によって署名が施された時点で、クライアント4にとって有効な証明書となる。
【0068】
セキュリティ保証局2は自身の公開鍵と秘密鍵のペアを作成し、既存の認証局からPKCの発行を受けておく。また、クライアント4は事前にセキュリティ保証局2のPKC108を受信し、保持しておく(ステップS21)。サーバ3はIDS32/VDS33やOS/アプリケーションのバージョンおよびパターンファイルの更新を行う(ステップS22)。続いて、サーバ3は、上記のセキュリティ対策の更新に伴って、セキュリティ証明書への署名要求を示す情報をセキュリティ保証局2へ送信する(ステップS23)。
【0069】
この情報を受信したセキュリティ保証局2は、サーバ3におけるIDS32およびVDS33の起動状態やパターンファイルの状態等を確認するために、前述した動作と同様にして攻撃パケットを連続的に生成し、サーバ3へ送信する(ステップS24;外部監査)。サーバ3において、通信部31は攻撃パケットを受信し、IDS32へ出力する。IDS32は記憶部38から最新のパターンファイルを読み出し、そのパターンファイルに基づいてパケットを監視し、最新の攻撃パターンと一致するパケットを検知した場合には、その攻撃パターン名(シグネチャ名)、送信元IP、時刻情報等を記憶部38のログに記録する。
【0070】
セキュリティ保証局2からの攻撃パケットがサーバ3に到着した後、内部監査モジュール39は所定のタイミングで内部監査を行う。すなわち、内部監査モジュール39は、IDS32およびVDS33の起動状態やパターンファイルの状態を確認し、前述したACの発行に必要な情報104と同様の情報を取得する。また、内部監査モジュール39はOSやアプリケーションの状態について、不審なアプリケーションやPortの設定等を検査し、内部監査の結果を示す情報を生成する(ステップS25)。
【0071】
サーバ3は、内部監査モジュール39が取得した情報に基づいて仮のセキュリティ証明書109を生成し、セキュリティ保証局2へ送信する。また、サーバ3は、内部監査の結果を示す情報およびログの情報を内部/外部監査結果110としてセキュリティ保証局2へ送信する(ステップS26)。セキュリティ保証局2の通信部21は上記のセキュリティ証明書109および内部/外部監査結果110を受信し、サーバとの通信制御部23を介してサーバ認証部25へ出力する。
【0072】
サーバ認証部25は、サーバ3に最新のセキュリティ対策が施されて、適切に運用されているかどうか検証する。すなわち、サーバ認証部25は、擬似攻撃のパケットを生成する際に用いた最新のパターンファイルに基づいた攻撃パターンがログに記録されているかどうか検証すると共に、セキュリティ証明書109の形式が所定の形式に沿っているかどうか、必要な情報が格納されているかどうか等を検証する。検証の結果、最新の攻撃パターンに基づいて更新された攻撃パターンがログに記録されており、セキュリティ証明書109の形式等が所定の条件を満たしていた場合には、サーバ認証部25は、サーバ3のセキュリティレベルを確認することができたとし、セキュリティ保証局2の秘密鍵を用いて署名情報を生成し、セキュリティ証明書109に付加する。サーバ認証部25は、サーバとの通信制御部23および通信部21を介してサーバ3へこのセキュリティ証明書109を送信する。サーバ3は、セキュリティ保証局2によって送信されたセキュリティ証明書109を受信する(ステップS27)。
【0073】
なお、セキュリティ保証局2が外部監査を行わず、サーバ3からの署名要求に基づいてサーバ3へ内部監査を指示し、内部監査に基づいてサーバ3が生成したセキュリティ証明書109の形式的な検証を行い、セキュリティ証明書109に署名を施すのみとしてもよい。セキュリティ保証局2が外部監査を行い、外部監査の結果をサーバ3のセキュリティレベルの検証の材料とすることにより、サーバ3のセキュリティレベルをより確実に確認および保証することができる。
【0074】
クライアント4は、通信の開始時点において、サーバ3に対してセキュリティ証明書109の提示を要求する(ステップS28)。サーバ3において内部監査モジュール39は内部監査を行い(ステップS29)、IDS32およびVDS33やパターンファイル等の状態がセキュリティ証明書109に格納された情報と同じ状態であるかどうか確認し、同じ状態であった場合には、セキュリティ保証局2の署名が付加されたセキュリティ証明書109をクライアント4へ送信する(ステップS30)。クライアント4はセキュリティ証明書109を受信し、クライアント4の署名検証部41は、セキュリティ保証局2の公開鍵を用いて、セキュリティ証明書109に付加されている署名の検証を行う(ステップS31)。検証の結果、署名が有効であった場合には、クライアント4はサーバ3と通信を開始する。
【0075】
次に、本実施形態の他の変形例について説明する。図6は、本変形例に係る通信システムの構成を示すブロック図である。本変形例においても、認証局1の図示は省略されている。本変形例のセキュリティ保証局2は、セキュリティ証明書の有効性の管理を行う失効証明書管理部29を備えている。また、サーバ3において、通信モジュール40は、前述した通信部31や、クライアント通信制御部34、SCAとの通信制御部37等を含むサーバ3と外部装置との通信を制御するハードウェアまたはソフトウェアである。
【0076】
本変形例においては、本通信システムの実装を図る上で有効な以下の3点について詳述する。
(A)セキュリティ保証局2とサーバ3との間、サーバ3とクライアント4との間、およびセキュリティ保証局2とクライアント4との間において、TCP/UDP上で動く新たな通信プロトコル。
(B)セキュリティ証明書の発行処理および失効処理。特に、失効処理については、従来のCRLを用いる処理方式に代わって、同一の内容を保証する複数のセキュリティ証明書を一斉に失効させる処理方式を示す。
(C)サーバ3の内部監査モジュール39の耐タンパ化を図る手法。
【0077】
まず、図6に示される本通信システムの概略動作を説明する。セキュリティ保証局2は自身の公開鍵と秘密鍵のペアを作成し、既存の認証局からPKCの発行を受けておく。また、クライアント4は事前にセキュリティ保証局2のPKC111を受信し、保持しておく(ステップS41)。サーバ3はIDS32/VDS33やOS/アプリケーションのバージョンおよびパターンファイルの更新を行う(ステップS42)。続いて、サーバ3は、上記のセキュリティ対策の更新に伴って、セキュリティ対策システムの更新状態を示すと共に、セキュリティ証明書への署名要求を示す情報をセキュリティ保証局2へ送信する(ステップS43)。
【0078】
続いて、内部監査モジュール39はOSやアプリケーションの状態について、不審なアプリケーションやPortの設定等を検査し、内部監査の結果を示す情報を生成する(ステップS44)。通信モジュール40は、内部監査の結果を示す情報を内部監査結果112としてセキュリティ保証局2へ送信する。セキュリティ保証局2は内部監査結果112を受信する(ステップS45)。セキュリティ保証局2は、サーバ3におけるIDS32およびVDS33の起動状態やパターンファイルの状態等を確認するために、前述した動作と同様にして攻撃パケットを連続的に生成し、サーバ3へ送信する(ステップS46;外部監査)。
【0079】
サーバ3において、IDS32は、前述した動作と同様にして、最新の攻撃パターンと一致するパケットに係る情報を記憶部38のログに記録する。通信モジュール40はログの情報を外部監査結果113としてセキュリティ保証局2へ送信する。セキュリティ保証局2は外部監査結果113を受信する(ステップS47)。内部監査と外部監査はどちらから先に行ってもよいが、本変形例においては内部監査が先に行われるものとする。
【0080】
セキュリティ保証局2は、前述した動作と同様にして、内部監査結果112および外部監査結果113に基づいて、サーバ3に最新のセキュリティ対策が施されて、適切に運用されているかどうか検証する。すなわち、サーバ認証部25は、擬似攻撃のパケットを生成する際に用いた最新のパターンファイルに基づいた攻撃パターンがログに記録されているかどうか検証すると共に、内部監査結果112に必要な情報が含まれているか、内部監査結果112によって示されるサーバ3のセキュリティ対策が最新のものであるかどうか等を検証する。
【0081】
検証の結果、最新の攻撃パターンに基づいて更新された攻撃パターンがログに記録されており、内部監査結果112が所定の条件を満たしていた場合には、サーバ3のセキュリティレベルを確認することができたとし、サーバ認証部25は、セキュリティ保証局2の秘密鍵を用いて署名情報を生成し、その署名情報を付加したセキュリティ証明書114を生成する。サーバ認証部25は、サーバとの通信制御部23および通信部21を介してサーバ3へセキュリティ証明書114を送信する。サーバ3はセキュリティ証明書114を受信する(ステップS48)。
【0082】
クライアント4は、通信の開始時点において、サーバ3に対してセキュリティ証明書114の提示を要求する(ステップS49)。サーバ3の通信モジュール40は、セキュリティ保証局2の署名が付加されたセキュリティ証明書114をクライアント4へ送信する(ステップS50)。本変形例においては、高速化のため、サーバ3の内部監査は省略されるものとする。サーバ3は、クライアント4からのセキュリティ証明書の提示要求に備えて、定期的に内部監査を行ってもよい。クライアント4はセキュリティ証明書114を受信し、署名検証部41は、セキュリティ保証局2の公開鍵を用いて、セキュリティ証明書114に付加されている署名の検証を行う(ステップS51)。
【0083】
検証の結果、署名が有効であった場合に、クライアント4はサーバ3へセキュリティ証明書114全体を送信するか、セキュリティ証明書114に付与されている証明書ID(後述するシリアル番号)を送信する(ステップS52)。セキュリティ保証局2の通信部21はセキュリティ証明書114または証明書IDを受信し、クライアントとの通信制御部24を介して失効証明書管理部29へ出力する。詳細は後述するが、失効証明書管理部29はセキュリティ証明書114が有効であるか失効であるかを検証し、検証結果を示す情報をクライアントとの通信制御部24へ出力する。クライアントとの通信制御部24は、通信部21を介して検証結果の情報をクライアント4へ送信する(ステップS53)。
【0084】
クライアント4は検証結果の情報を受信し、その情報に基づいて、セキュリティ証明書114の有効性を判断する。セキュリティ証明書114が失効しておらず、有効なセキュリティ証明書であると判断できた場合に、クライアント4はサーバ3との通信を開始する。
【0085】
次に、セキュリティ保証局2とサーバ3との間、サーバ3とクライアント4との間、およびセキュリティ保証局2とクライアント4との間の通信に用いられる通信プロトコルについて説明する。従来のPKIにおいては、公開鍵証明書への署名を受けたいサーバは、公の認証局に対して身元情報や公開鍵情報を、郵送等の物理的な経路を使って送っている。場合によっては、これらの情報がネットワーク経由で送られることもあるが、認証局側では何らかの物的証明を参照して、送られてきた情報の正当性の担保を取っている。
【0086】
しかしながら、セキュリティ証明書の場合、未知の攻撃やウィルスが発見されるたびに証明書の廃棄と更新を図る必要があり、即時性を保つためにも、全てネットワーク経由でオンライン化された処理が行われなければならない。ネットワーク経由で相手を確実に認証し、情報を盗聴されないようにするためにも、通信方式の検討は重要である。
【0087】
まず、セキュリティ保証局2とサーバ3との間の通信プロトコルを説明する。セキュリティ保証局2とサーバ3との間の通信は、既存の相互認証および暗号化プロトコルで安全な通信路を確保するフェーズから開始する。続いて、開始要求フェーズ、安全性評価フェーズ等が実施され、最後にセキュリティ証明書の発行が行われて終了する。
【0088】
図7は、セキュリティ保証局2およびサーバ3間の相互認証・暗号化の通信シーケンスを示している。相互認証と暗号化は、既存のSSL(Secure Socket Layer)やIPsec等のプロトコルを利用すればよく、証明書発行フェーズと独立しており、各種の相互認証・暗号化プロトコルを適用することができる。図7(a)は、SSLを用いた相互認証・暗号化の通信シーケンス例である。TCPの3Wayハンドシェーク(ステップS701a)に続いて、セキュリティ保証局2およびサーバ3はSSLの相互認証・暗号化を行い(ステップS702a)、後述する証明書発行処理を行う(ステップS703a)。SSLの終了処理(ステップS704a)およびTCPの終了処理(ステップS705a)が行われ、相互認証・暗号化が終了する。
【0089】
図7(b)は、IPsecを用いた相互認証・暗号化の通信シーケンス例である。IPsecの相互認証・暗号化(ステップS701b)に続いて、セキュリティ保証局2およびサーバ3はTCPの3Wayハンドシェークを行い(ステップS702b)、後述する証明書発行処理を行う(ステップS703b)。TCPの終了処理(ステップS704b)およびIPsecの終了処理(ステップS705b)が行われ、相互認証・暗号化が終了する。
【0090】
図8は、証明書発行フェーズの通信シーケンス例を示している。図8(a)は、証明書発行アプリケーション層で通信処理の確実性を持たせた方式であり、図8(b)は、確実性を下位通信レイヤに委ねて高速性を持たせた方式である。高速性を持たせた方式は、確実性を持たせた方式の処理から確認処理を省いたものとなっている。以下、確実性を持たせた方式を基準にして説明する。
【0091】
証明書発行のための通信においては、様々な形式およびサイズの情報を交換する必要があるため、自由フォーマットのテキストを通信するのに適したタグ囲み(<と>、および</と>の間に、情報の種別を表すテキストが挿入されたタグ同士の間に、情報の内容を表すテキストが挿入される文書構造)を用いることにする。すなわち、通信相手に通知される情報に対してタグが付加された形式のデータが送受信される。タグによって情報の種別が判断(識別)され、タグによって囲まれたテキストを参照することによって、情報の内容が判断(識別)される。
【0092】
相互認証・暗号化(ステップS801a、ステップS801b)開始フェーズにおいては、サーバ3はセキュリティ保証局2に対して、セキュリティ証明書の発行のための通信フェーズの開始を通知する。サーバ3は、開始パケットをセキュリティ保証局2へ送信し、セキュリティ証明書の発行要求を通知する(ステップS802a)。セキュリティ保証局2は、そのレスポンスとして確認パケットをサーバ3へ返信する(ステップS803a)。図9は開始パケットおよび確認パケットの内容を示している。「*」印はオプションである(以下同様)。
【0093】
続いて、更新・状態通知フェーズにおいて、サーバ3は、セキュリティ対策に関わる更新された情報を、更新・状態通知パケットによってセキュリティ保証局2に通知する(ステップS804a、ステップS802b)。この更新・状態通知パケットに含まれる情報は、セキュリティ対策システムの状態を示す状態情報(通知情報)であり、内部監査モジュール39が収集する。セキュリティ保証局2は、更新・状態通知パケットを受信し、確認パケットをサーバ3へ返信する(ステップS805a)。図10は、更新・状態パケットおよび確認パケットの内容を示している。
【0094】
図10において、「name」 印はOSやIDSの名前を、「version」 印はそれらのバージョン情報を、「pattern」印はパッチやパターンファイル情報を通知するための識別子である。「UP」 印は、更新された情報を表し、この印のない数値やテキスト情報のみが記載されているものは、更新のない現状を表している。VDS等のタグが例示されていないが(例:<status-vds>)、この場合には、VDSを持っていないか、もしくはVDSに関しては、保証の必要がないことを表している。
【0095】
多数のサーバのセキュリティ状態を保証するセキュリティ保証局2が各サーバの状態履歴管理をしなくてもよいように、各サーバは、セキュリティ保証局2に通知する情報に現状と更新の両状態の情報を含めることにする。これにより、セキュリティ保証局2はセキュリティ証明書の発行要求単位で発行の可否を判断することができる。もし、セキュリティ保証局2が各サーバの状態の履歴管理機能を有する場合には、各サーバが更新情報のみを通知することによって、セキュリティ保証局2は証明書の発行可否を判断することができる。署名を受ける各サーバの公開鍵情報(<pub-key>***</pub-key>参照)も通知される。
【0096】
続いて、内部監査指示フェーズにおいて、セキュリティ保証局2は、サーバ3に対して、内部監査すべき項目を要求し(ステップS806a、ステップS803b)、サーバ3はその要求に従った監査結果を報告する(ステップS807a、ステップS804b)。報告を受けたセキュリティ保証局2は確認パケットをサーバ3へ送信する(ステップS808a)。図11は内部監査指示パケット、内部監査結果パケット、および確認パケットの内容を示している。
【0097】
内部監査の結果は、サーバ3のセキュリティ対策システムの状態を示す状態情報であり、更新・状態通知フェーズにおいて、サーバ3がセキュリティ保証局2に通知した状態情報(通知情報)よりも詳細なセキュリティ対策システムの状態を示している。内部監査指示パケットによって、サーバ3が管理しているファイル(例:syslog)や、起動中のプロセス(例:psコマンド)をチェックすることが指示される。これに従い、サーバ3は、要求された情報をテキスト情報として含む内部監査結果パケットをセキュリティ保証局2へ返信する。返信サイズが大きくなる場合には、複数のパケットに分割される場合もある。場合によっては、サーバ3は特徴のみをハッシュ値として通知することもある。また、セキュリティ保証局2が、返信すべき箇所を指定することもあり、例えばキーワードや時刻情報をサーバ3に通知することで、返信すべき箇所を絞り込む。
【0098】
続いて、外部監査フェーズにおいて、セキュリティ保証局2からサーバ3に対する、攻撃パケット等による外部監査が行われる(ステップS809a、ステップS805b)。外部監査フェーズに続く外部監査指示フェーズにおいて、セキュリティ保証局2は、サーバ3側に記録された外部監査の結果を収集するため、外部監査指示パケットをサーバ3へ送信する(ステップS810a、ステップS806b)。サーバ3は、外部監査の結果をテキスト情報として含む外部監査結果パケットをセキュリティ保証局2へ送信する(ステップS811a、ステップS807b)。外部監査結果パケットを受信したセキュリティ保証局2は確認パケットをサーバ3へ送信する(ステップS812a)。
【0099】
図12は、外部監査指示パケット、外部監査結果パケット、および確認パケットの内容を示している。IDS等に記録されたログ情報を収集するために、外部監査指示パケットによって、収集すべき情報が指定される。外部監査は、セキュリティ保証局2から実施するとは限らない。また監査を実施するタイミングもまちまちである。さらに、結果ログ等の情報は膨大なサイズになる。これらのことより、収集すべき外部監査結果の箇所を特定する必要があり、セキュリティ保証局2は、外部監査指示パケットによって、外部監査を行ったIPアドレスや時刻、キーワード等を指定する情報を通知する。サーバ3は、指定された情報を、テキスト情報である外部監査結果パケットとして返信する。場合によっては、特徴のみをハッシュ値として通知することもある。
【0100】
続いて、セキュリティ証明書フェーズにおいて、セキュリティ保証局2は、内部監査と外部監査の結果、セキュリティ対策がサーバ3に正しく設定されている場合には、サーバ3に対して、セキュリティ証明書を発行して返信する(ステップS813a、ステップS808b)。サーバ3にセキュリティ対策が正しく設定されていない場合や、サーバ3から情報を正しく受け取れなかった場合には、セキュリティ保証局2はエラー情報(未対策通知パケット)を返信する。セキュリティ証明書を受け取ったサーバ3は確認パケットをセキュリティ保証局2へ送信する。図13はセキュリティ証明書パケットおよび未対策通知パケットの内容を示している。
【0101】
セキュリティ証明書には、発行者のIPアドレスと名前、バージョン番号、署名方式、署名の発行年月日、有効期限、サーバ名、サーバの公開鍵情報、セキュリティレベルが付与される。場合によっては、OSやIDS・VDSの状態が正しいということを示す情報も含まれる。また、後述するように、OSやIDS・VDSの状態に関する情報が、セキュリティ保証局2の公開鍵によって埋め込まれる場合もある。セキュリティ保証局2は、この情報を自身の秘密鍵で解くことによって、サーバ3の状態を示す情報を取り出し、セキュリティ証明書単位での有効性の確認を行う。
【0102】
セキュリティ証明書の末尾には署名情報が付与される。署名情報として、OSやIDSの状態を表す署名と、セキュリティ証明書全体の正当性を表す署名とがある。OSやIDSの状態をテキスト文のまま記載してしまうと、悪意の侵入者にセキュリティ対策情報(どのようなセキュリティ対策が施されているのかを表すセキュリティ対策の種別等を示す情報)を公開してしまうことが予想されるため、セキュリティ保証局2は、セキュリティ対策情報を抽象化した安全指数(<level>***</level>参照)をセキュリティ証明書に付加する。セキュリティ保証局2はセキュリティ対策情報と安全指数との対応表を管理しており、サーバ3から通知されたセキュリティ対策情報に基づいて、サーバ3の安全指数を決定する。もし、内部監査や外部監査の結果、サーバ3のセキュリティ対策が十分でないと判断した場合には、セキュリティ保証局2は、未対策通知パケットによって問題箇所をサーバ3に通知する。続いて、相互認証・暗号化終了フェーズを経て、通信が終了する(ステップS815a、ステップS809b)。
【0103】
本変形例においては、セキュリティ保証局2がセキュリティ証明書を発行しているが、前述した変形例と同様に、サーバ3が仮のセキュリティ証明書をセキュリティ保証局2へ送信し、セキュリティ証明書に対して、セキュリティ保証局2が署名を施すようにしてもよい。この場合の通信においても、本変形例と同様に、タグ囲みを用いた通信が行われる。
【0104】
次に、サーバ3およびクライアント4間の通信プロトコルを説明する。図14はサーバ3およびクライアント4間の通信シーケンスを示している。図14においては、証明書要求アプリケーションがTCPレイヤの上で動いている様子が示されている。図14(a)は、通信処理の確実性を持たせた方式であり、図14(b)は、確認処理を省いて高速性を持たせた方式である。
【0105】
TCPの3Wayハンドシェーク(ステップS1401a、ステップS1401b)に続いて、相互認証および暗号化が行われ(図示せず)、確実性を持たせた方式では開始パケットおよび確認パケットの送受信が行われる(ステップS1402a、ステップS1403a)。続いて、クライアント4は、サーバ3に対して、証明書要求パケットを送信する(ステップS1404a、ステップS1402b)。サーバ3は証明書要求パケットを受信し、証明書要求パケットによる要求に基づいて、セキュリティ証明書パケットをクライアント4へ送信する(ステップS1405a、ステップS1403b)。
【0106】
図15は、証明書要求パケットおよびセキュリティ証明書パケットの内容を示している。セキュリティ証明書パケットには、発行者名、バージョン、署名方式、発効日時、有効期限、サーバ名、セキュリティレベル等の情報がテキストとして含まれている。場合によっては、OSやIDSの状態が正しいことを通知するための情報も含まれる(<os-status>***</os-status>および<ids-status>***</ids-status>参照)。最後にセキュリティ保証局2の署名情報が付与される(<hash>***</hash>参照)。
【0107】
確実性を持たせた方式では、セキュリティ証明書パケットを受信したクライアント4は、確認パケットをサーバ3へ送信する(ステップS1406a)。続いて、TCPの終了処理が行われて、処理が終了する(ステップS1407a、ステップS1404b)。
【0108】
次に、セキュリティ保証局2およびクライアント4間の通信プロトコルを説明する。クライアント4側でのセキュリティ証明書の検証は、処理負荷の軽減と、セキュリティに関する確実性との観点から次の2つのレベルがある。
Level1)既に取得しているセキュリティ保証局2の公開鍵を用いたローカル検証
Level2)セキュリティ証明書の失効状態を確認するためにセキュリティ保証局2に問い合わせるオンライン検証
【0109】
Level1を実現するには、既存のPKIモデルと同様に、クライアント4が予めセキュリティ保証局2の公開鍵証明書を取得しておくことによって、セキュリティ証明書に付随する署名の有効性を検証することができる。クライアント4は外部との通信を必要とせず、処理負荷は軽い。
【0110】
しかしながら、未知の攻撃やウィルスが新たに出回り始めた場合に、セキュリティ証明書の有効性を確認する必要が生じる。有効期限内のセキュリティ証明書についても、クライアント4からセキュリティ保証局2に対して、失効状態の確認を頻繁に図ることが想定される。このとき、確実性を重視したLevel2のオンライン検証が必要になる。以下、Level2の方式を実現する手法を説明する。図16はクライアント4およびセキュリティ保証局2間のLevel2の通信シーケンスを示している。図16(a)は、通信処理の確実性を持たせた方式であり、図16(b)は、確認処理を省いて高速性を持たせた方式である。
【0111】
TCPの3Wayハンドシェーク(ステップS1601a、ステップS1601b)に続いて、相互認証および暗号化が行われ(図示せず)、確実性を持たせた方式では開始パケットおよび確認パケットの送受信が行われる(ステップS1602a、ステップS1603a)。続いて、クライアント4は、サーバ3から受信したセキュリティ証明書をセキュリティ保証局2へ送信し、セキュリティ証明書の有効性の確認を要求する(ステップS1604a、ステップS1602b)。
【0112】
セキュリティ保証局2はセキュリティ証明書を受信し、自身の公開鍵でセキュリティ証明書に署名したOSやIDSの状態情報を、秘密鍵を用いて取り出し、その有効性を確認し、有効性の確認結果をクライアント4に返信する(ステップS1605a、ステップS1603b)。このとき、クライアント4には、セキュリティ保証局2からの情報であることを保証するために、返信パケットの全体に対してセキュリティ保証局2の秘密鍵で署名した情報が送信される。図17はセキュリティ証明書パケットの内容、および有効性の確認結果である結果パケットの内容を示している。確実性を持たせた方式では、確認結果を示すパケットを受信したクライアント4は確認パケットをセキュリティ保証局2へ送信する(ステップS1606a)。続いて、TCPの終了処理(ステップS1607a、ステップS1604b)が行われ、処理が終了する。
【0113】
次に、セキュリティ保証局2によるセキュリティ証明書の発行および失効の手法を説明する。従来のPKIでは、各サーバに発行された証明書は、シリアル番号(前述した証明書ID)で管理されている。各証明書の有効期限は数年単位で設定されており、ひとたび発行された証明書の殆どが、有効期限内に失効することはない。よって、発行(更新)と失効の頻度は低く、個々の履歴をシリアル番号で管理することは可能である。このシリアル番号をCRL(Certificate Revocation List)に登録することによって、証明書の管理が実現されている。
【0114】
しかしながら、本実施形態におけるセキュリティ証明書の場合、新たな攻撃やウィルスが発見されるたびに、OSやIDS・VDSの設定ファイルが更新されることになり、発行(更新)と失効の頻度が高く、セキュリティ保証局2は膨大な数のセキュリティ証明書の状態を管理することになる。以下では、従来のCRLによる管理手法の適用も検討するが、セキュリティ保証局2側で、発行したセキュリティ証明書の履歴管理を行う必要のない管理手法についても検討が必要である。
【0115】
以下では、セキュリティ証明書の中に、セキュリティ保証局2のみが読み出せるサーバ3のセキュリティ対策情報を持たせることによって、セキュリティ保証局2はセキュリティ証明書を参照するだけで、その有効性(失効性)を判定することができる方式を説明する。これは、サーバ3のセキュリティ対策情報を、クライアント4に取得されないようにするために、セキュリティ証明書内に暗号化して保存する手法であり、悪意のクライアント対策を考慮した安全性を重視した方式である。
【0116】
また、頻繁にセキュリティ証明書の有効性を確認しなければならない本実施形態の場合、クライアント4がセキュリティ保証局2に問い合わせる頻度が高くなり、セキュリティ保証局2側で輻輳する可能性もある。したがって、発行した個々のセキュリティ証明書を管理するのではなく、グループ単位で有効性を判定する手法についても検討する必要がある。
【0117】
以下では、失効処理の負荷の軽減を目的として、同一種類のOSやIDS・VDSが適用されているサーバに対して、同一種類のセキュリティ証明書を発行することで、セキュリティ証明書の種別ごとに一斉に失効させる手法を説明する。これによって、セキュリティ証明書の失効判定処理の簡易化を図ることができる。
【0118】
まず、CRLによるセキュリティ証明書の管理手法を本実施形態に適用した場合を説明する。セキュリティ保証局2は、発行した個々のセキュリティ証明書に、固有のシリアル番号を付与する。セキュリティ証明書を失効させる際には、セキュリティ保証局2は、この番号をCRLに登録する。この手法は、失効管理を実現する従来のPKIモデルと同じ方式である。この場合、OSやIDS・VDSに関する情報をセキュリティ証明書に付与する必要はない。セキュリティ証明書の有効性を判断する場合、セキュリティ保証局2の失効証明書管理部29は、セキュリティ証明書に付与されているシリアル番号とCRL中のシリアル番号とを照合し、両者が一致した場合に、そのセキュリティ証明書が失効状態である(有効でない)と判断する。
【0119】
次に、セキュリティ証明書の中にサーバ3のセキュリティ対策情報(どのようなセキュリティ対策が施されているのかを表すセキュリティ対策種別等を示す情報)を、セキュリティ保証局2のみが読み出せるように格納する手法を説明する。セキュリティ保証局2から発行されたセキュリティ証明書にサーバ3のセキュリティ対策情報を、セキュリティ保証局のみが読み出せる手法で埋め込んでおくことによって、クライアント4からセキュリティ保証局2に対して、有効性に関する問い合わせがあった場合にも、セキュリティ保証局2は、セキュリティ証明書の情報を参照するだけで、その有効性を判定することができる。ここで注意すべきことは、セキュリティ証明書の中に、OSやIDS・VDSの名前やバージョン等の情報を直接(誰でも読み出せる形で)埋め込まないことである。
【0120】
セキュリティ保証局2のサーバ認証部25は、セキュリティ証明書を発行する際に、セキュリティ証明書に付与するセキュリティ対策情報として、サーバ3から通知されたOSやIDS・VDSの名前およびバージョン・パターンファイル情報と、パディングのための乱数とを1つの情報として扱い、この情報に対して、自身の公開鍵で暗号化を施す。セキュリティ保証局2は、暗号化して得た暗号データをセキュリティ証明書に付加する。暗号化の様子は、図13等における証明書タグ<secret-os> *** </secret-os> や <secret-ids>*** </secret-ids> で表されている。
【0121】
セキュリティ保証局2は各セキュリティ証明書の固有のシリアル番号を管理することはせず、セキュリティ対策の種別を示すOSやIDS・VDSのバージョンと、その有効性を示す情報とが関連付けられたテーブル(失効情報テーブル)を記憶部28に格納している。セキュリティ証明書の有効性を判断する際に、サーバ認証部25は、セキュリティ証明書に含まれる、暗号化されたセキュリティ対策情報をセキュリティ保証局2の秘密鍵で復号化する。サーバ認証部25は、記憶部28から失効情報テーブルを読み出し、復号化によって得たセキュリティ対策情報の内容と照合することによって、セキュリティ証明書の有効性を判断する。すなわち、セキュリティ証明書に含まれていたセキュリティ対策情報によって示されるOS等のバージョンが、失効情報テーブル上で失効となっていた場合、サーバ認証部25は、セキュリティ証明書が失効していると判断する。
【0122】
この手法によれば、セキュリティ保証局2は、膨大な数の個々のセキュリティ証明書のシリアル番号を管理する必要がなくなるので、セキュリティ保証局2において必要な記録容量を削減し、セキュリティ保証局2の管理コストを低減することができる。また、サーバ3のセキュリティ対策情報が暗号化されてセキュリティ証明書に付加されているので、サーバ3のセキュリティ対策情報が漏洩する危険性を低減することができる。
【0123】
次に、種別ごとにセキュリティ証明書を一斉に失効させる手法を説明する。サーバ認証部25は、同一種類のOSやIDS・VDSが適用されている複数のサーバに対して、同一種類の識別情報を有するセキュリティ証明書を発行する。サーバ認証部25は、セキュリティ対策種別を識別するシリアル番号をセキュリティ証明書に付与する。セキュリティ対策種別は、OSやIDS・VDSのバージョンによって示される。
【0124】
記憶部28には、セキュリティ対策種別およびそのシリアル番号と、有効性を示す情報とが関連付けられた失効情報テーブルが格納されている。サーバ認証部25は、クライアント4から受信されたサーバ3のセキュリティ証明書に含まれるシリアル番号と、記憶部28から読み出した失効情報テーブル中のシリアル番号とを照合する。両者が一致した場合、サーバ認証部25は、失効情報テーブルの内容に基づいて、そのバージョンの有効性を判断する。そのバージョンが失効状態である場合、サーバ認証部25はセキュリティ証明書が失効状態である(有効でない)と判断する。
【0125】
セキュリティ証明書が失効するタイミングは、セキュリティ証明書の有効期限内にOSのバージョンが更新される場合や、IDS・VDSの検知パターンファイルが公開される場合である。上記のように、同一種類のセキュリティ対策種別を有する複数のサーバに対して、セキュリティ対策種別に関して同一内容のセキュリティ証明書が発行されるため、OS、IDS、およびVDSの個々のセキュリティ対策種別ごとにセキュリティ証明書が一斉に失効することになる。
【0126】
失効は、セキュリティ対策種別ごとに生成されたセキュリティ証明書内のシリアル番号で管理される。この手法でセキュリティ保証局2から公開される失効情報は、有効期限内に失効することになったセキュリティ証明書のシリアル番号のみとする。図13等に示されるセキュリティ証明書中の<secret-os>***</secret-os> や <secret-ids>***</secret-ids> で表されている情報の箇所へ、セキュリティ対策種別ごとのシリアル番号が付与される。この場合、セキュリティ証明書全体へのシリアル番号は不要になる。
【0127】
以下、セキュリティ対策種別ごとに付与するシリアル番号から、セキュリティ対策情報を推測し難くする手法について、OS種別とバージョンを例にして説明する。OSには複数種類あり、そのバージョンにも様々なものがある。図18は、シリアル番号および失効状態のOSならびにバージョン情報を管理する失効情報テーブルの様子を示している。このテーブルは、セキュリティ保証局2の失効証明書管理部29によって作成されて、管理される。また、このテーブルは記憶部28に格納されている。
【0128】
シリアル番号は、A、B、C・・・で表されるグループIDと昇順数値とによって構成されている。失効状態に関しては、あるグループのある数値が失効した場合、同じグループ内のその数値以下の全ての数値が失効となる。例えばグループDの004まで失効した場合、Dグループのそれ以下(000〜003)の数値が関連付けられたセキュリティ証明書は全て失効される。図18(a)においては、グループBの000〜002およびグループDの000〜001に関連付けられたセキュリティ証明書は全て失効している。失効情報テーブルには、グループBの002およびグループDの001が失効しているという情報が含まれている。その数値以下の数値は全て失効しているから、全ての昇順数値に対して失効しているか否かの情報(フラグ等)を用意する必要はない。これによって、セキュリティ保証局2において必要な記録容量を削減し、セキュリティ保証局2の管理コストを低減することができる。
【0129】
セキュリティ対策情報を推定され難くするために、同じOSとバージョンであっても、複数のグループIDと複数の数値で管理されることにする。図18には、OSxxxとOSyyyが複数のグループで管理されている様子や、OSxxx−v1.1とOSzzz−v1.2が複数の数値で管理されている様子が示されている。同じOSとバージョンを持つサーバがあったとしても、セキュリティ証明書によってはグループIDや昇順数値が異なる場合もあり、互いに同じ設定であることを認識できないようになる。推定の困難性は、グループIDの数や昇順数値の数に依存する。
【0130】
OSyyyのバージョン1.3までが失効状態であった場合(図18(a))、Dグループの000〜001が失効となっている。Dグループの002以後には別のOSxxxの管理が割り当てられている。さらに時間が進み、OSxxxのバージョン1.2まで失効されていることを想定する(図18(b))。このとき、Aグループの003まで全て失効された状態となり、A−004以後には別のOSyyyを割り当てることができる。
【0131】
図18(a)の状態では、A−003は失効しておらず、この状態でA−004以後に別のOSyyyを割り当ててしまうと、OSxxx−v1.2よりもOSyyyの方が先に失効してしまう可能性がある。したがって、図18(b)の状態となってから、A−004以後に別のOSyyyが割り当てられるようになる。失効証明書管理部29は、シリアル番号の昇順数値を付与する際に、上記のように、ある昇順数値が付与されたバージョンが失効であった場合に、同一グループのその数値以下の昇順数値が付与されたバージョンが全て失効状態となっているという関係を満たすように、昇順数値を付与する。
【0132】
悪意のサーバが様々なOSやバージョン情報をセキュリティ保証局2に申請して、多数の証明書を集めることによって、シリアル番号の対応表を推定することができる可能性がある。この攻撃に対しては、セキュリティ保証局2が、セキュリティ証明書の発行頻度を制限することによって、防ぐことができる。
【0133】
セキュリティ保証局2はシリアル番号と、その番号を最後に発行した日時情報とを管理しておく。この日時情報を基に、有効期限の切れたセキュリティ証明書のシリアル番号は公開しないことにして、失効情報の量を軽減させる。図18(b)では、B−002が、有効期限切れのセキュリティ証明書に付与されたシリアル番号であり、A−003とD−002の2つが、失効情報としてセキュリティ保証局2から公開される。
【0134】
上述した手法によれば、セキュリティ対策種別に関して同一内容のセキュリティ証明書の有効性をグループ単位の数値で判断することができ、セキュリティ保証局2の負荷を軽減することができる。また、失効したOS等のバージョンのグループIDと昇順数値を公開しておくことによって、クライアント側でも容易にセキュリティ証明書の失効判定を行うことができる。
【0135】
また、同一のOSやIDS・VDS等のバージョンに対して、グループIDおよび昇順数値の組を複数割り当てることによって、サーバのセキュリティ対策情報を推測し難くすることができる。さらに、前述した、サーバ3のセキュリティ対策情報をセキュリティ保証局2が暗号化してセキュリティ証明書に埋め込む手法と比較して、セキュリティ証明書のサイズを小さくすることができる。
【0136】
なお、本変形例において説明したセキュリティ証明書の発行および失効の手法を、前述した変形例に適用してもよい。
【0137】
次に、サーバ3の内部監査モジュール39の耐タンパ化を図る手法を説明する。セキュリティ証明書の内容を保証するために、内部監査モジュール39の役割は重要である。もし内部監査モジュール39に関わる処理が攻撃され、IDS32やVDS33が停止しているにも関わらず、サーバ3がセキュリティ証明書をクライアント4に返信していたら、本実施形態によるPKI基盤モデルの信用が失われてしまうことになる。
【0138】
攻撃例として、i)内部監査モジュール39が起動しているサーバ3のOS自体が攻撃されて乗っ取られることで、OSが内部監査モジュール39に偽の情報を返信する攻撃がある。また、ii)内部監査モジュール39自体が攻撃されて、なりすまされることで、セキュリティ保証局2と偽の情報を交換する攻撃や、クライアント4に偽のセキュリティ証明書を返信してしまう攻撃が考えられる。そこで本変形例では、最も重要な役割を果たす内部監査モジュール39の耐タンパ化を、TCG(Trusted Computing Group)で検討されているTPM(Trusted Platform Module)の技術を用いて実現する手法と、スマートカード(ICカード)を用いて実現する手法とを提案する。
【0139】
まず、TCGについて説明する。TCGとは、ハードウェアからBIOS、OSに至るまで、アプリケーションを実行する環境を、信頼できるプラットフォームとして実現することを目指す業界標準化団体である。具体例として、コンピュータ上にハードウェアチップを組み込み、ソフトウェアから不正に操作することができない秘密情報(暗号鍵等)をそのハードウェアチップに格納するといったことが挙げられる。このチップのことをTPMという。いわゆる、コンピュータに内蔵されたセキュリティチップのことである。
【0140】
TPMを構成する機能として必要なものを以下に示す。
(1)プラットフォーム完全性の計測:BIOS、OS、ソフトウェアの改竄を発見するための、ソフトウェアのハッシュ値を保存する機能。
(2)プラットフォームの認証:正当なTPMが使用されていることを保障するための、TPM内に格納する秘密鍵の生成、保持機能。
(3)保護メモリ領域:秘密鍵を安全に保管するための、保護された記憶機能。
(4)暗号処理用コプロセッサ:暗号処理を安全に行うための公開鍵暗号演算、乱数発生、ハッシュ演算機能。
【0141】
TPMが上述した機能を備えることによって、図19に示されるように、TPMの実装位置を信頼点として、OS、Boot Loader、BIOS等の完全性の確認が可能となり、信頼性が保たれる(信頼の連鎖)。例えば、TPMにはOS等のハッシュ値が格納されており、OS等が改竄された場合には、そのハッシュ値が変化するので、改竄できないTPM中のハッシュ値と比較することによって、OS等の改竄の有無を検出することができる。
【0142】
一方、スマートカード(ICチップとも呼ばれる)とは、CPUやメモリ、セキュリティ回路等のICチップを組み込んだクレジットカード大のプラスチックカードである。スマートカードは、外部からの物理的な攻撃を受けた場合、チップ自体が破損する。また、守るべきプログラムはROMに焼き付けられており、外部のソフトウェア等でそのプログラムを書き換えることは不可能である。また、スマートカードは、重要な情報に暗号化を施して記憶することができる等の特徴を持っている。セキュリティ保証基盤で利用するスマートカードは、サーバ3のインタフェースに差し込む形態とし、暗号化等の演算能力、秘密情報の記憶領域、通信機能をスマートカードに持たせる。
【0143】
サーバ3内部にセキュリティチップを持たせて、そこで守るべき秘密情報と、この秘密情報を基に間接的に守られる情報を以下で列挙する。ちなみに、セキュリティチップを信頼点として、信頼の連鎖により間接的に守られる情報は、通常の記憶領域(ハードディスク等)で管理される。
【0144】
TPMやスマートカードの記憶領域、計算処理能力、通信能力が高い場合、守るべき情報と信頼の連鎖で守られる情報は図20(a)の通りとなる。セキュリティチップの能力が高い場合には、BIOS、Boot Loader、OSの他、内部監査モジュール39や通信インタフェース(通信モジュール40)の機能を実現する処理回路自体をセキュリティチップ内に実装することができる。また、TPMやスマートカードの記憶領域、計算処理能力、通信能力が低い場合、守るべき情報と信頼の連鎖で守られる情報は図20(b)の通りとなる。セキュリティチップの能力が低い場合には、内部監査モジュール39等の機能を実現する処理回路自体はセキュリティチップとは別のハードウェアによって構成し、セキュリティチップ内に内部監査モジュール39等のハッシュ値を格納しておく。
【0145】
次に、セキュリティGW(ゲートウェイ)に対して、耐タンパ化されたモジュールを実装した例を説明する。TPMやスマートカードを用いて信頼点を作成するには、サーバにセキュリティチップを実装するよりも、ブロードバンドルータやホームGWに実装してセキュリティGWとする方が容易に実現できる。図21は、セキュリティGWにセキュリティチップを実装した場合の通信システムの構成を示している。
【0146】
図において、セキュリティGW9に高性能なセキュリティチップ91が実装され、セキュリティGW9自身のOS、内部監査モジュール、通信モジュール、秘密鍵が、セキュリティチップ91によって管理されている。セキュリティ保証局2やクライアント4との通信処理は、セキュリティチップ91内に設けた通信モジュールを経由して行われる。内部監査モジュールは、セキュリティGW9自身のIDS・VDSの状態を監視する。また、セキュリティチップ91は、LANに接続されている各種機器(図21の各種端末12やサーバ13等)のOSやアプリケーション、場合によってはVDS等の状態を、外部監査によって監視する。
【0147】
なお、本変形例において説明した内部監査モジュール39の耐タンパ化の手法を、前述した変形例に適用してもよい。
【0148】
上述したように本実施形態においてサーバ3は、自身のセキュリティレベル(通信上の安全性)を示すIDS32またはVDS33に関しての、ACの発行に必要な情報104をセキュリティ保証局2へ送信する。セキュリティ保証局2は、ACの発行に必要な情報104に基づいてサーバ3のセキュリティレベル(通信上の安全性)を検証し、セキュリティレベルを確認することができた場合に、AC105を発行し、サーバ3へ送信する。また、サーバ3は、クライアント4からの接続要求があった場合に、クライアント4へAC105を送信し、クライアント4はAC105に基づいて、サーバ3のセキュリティレベルを検証する。
【0149】
上記により、クライアント4は、サーバ3のセキュリティレベルが、第三者機関であるセキュリティ保証局2によって証明されていることをサーバ3との通信前にAC105から知ることができる。したがって、セキュリティ保証局2、サーバ3、およびクライアント4に対して上記のような機能を持たせることによって、通信相手がセキュリティ対策を施していることを保証し、より安全なネットワーク基盤を構成することができるようになる。
【0150】
また、本実施形態の他の動作によれば、サーバ3は、本人性(識別性)を示すPKC102をセキュリティ保証局2へ送信し、セキュリティ保証局2は、PKC102に基づいてサーバ3の本人性を検証し、本人性およびセキュリティレベルを確認することができた場合に、AC105を発行し、サーバ3へ送信する。さらに、サーバ3は、クライアント4からの接続要求があった場合に、クライアント4へPKC102を送信し、クライアント4は、PKC102に基づいて、サーバ3の本人性を検証する。上記により、通信相手がセキュリティ対策を施していることをより確実に保証することができる。
【0151】
また、本実施形態の他の動作によれば、セキュリティ保証局2およびサーバ3は、公開鍵暗号認証方式またはパスワード認証方式による両方向の認証に続いて暗号通信を行い、セキュリティ保証局2はサーバ3を遠隔操作し、ACの発行に必要な情報104に相当する情報をサーバ3から取得する。あるいは両方向の認証に続いてサーバ3がACの発行に必要な情報を主体的にセキュリティ保証局2へ送信する。これにより、上記と同様の効果を得ることができると共に、悪意のサーバがIDSやVDSによる通信の監視を行っていないにもかかわらず、ACの発行依頼を行う事態を防止し、サーバ3のセキュリティレベルをより確実に確認および保証することができる。
【0152】
また、本実施形態の他の動作によれば、サーバ3は、難読化等により耐タンパ性を有するプログラムに従って、IDS32またはVDS33の状態を示す状態情報を生成してセキュリティ保証局2へ送信し、セキュリティ保証局2は状態情報を受信し、状態情報の内容が、ACの発行に必要な情報104に含まれる情報の内容と一致するかどうか検証する。これにより、サーバ3のセキュリティレベルをより確実に確認および保証することができる。
【0153】
また、本実施形態の他の動作によれば、セキュリティ保証局2は、最新のパターンファイルに基づいた攻撃をサーバ3に対して行い、サーバ3のIDS32またはVDS33は、セキュリティ保証局2からの受信等により予め保持する最新のパターンファイルに基づいて、セキュリティ保証局2による攻撃を検知し、ログに記録する。サーバ3はログをセキュリティ保証局2へ送信し、セキュリティ保証局2は、サーバ3に対して行った攻撃がログに記録されているかどうか検証することにより、サーバ3が最新のパターンファイルに基づいたセキュリティ対策を行っているかどうか確認する。これにより、サーバ3のセキュリティレベルをより確実に確認および保証することができる。
【0154】
また、本実施形態の変形例によれば、サーバ3がIDS32およびVDS33の状態等を確認して仮のセキュリティ証明書109を発行し、このセキュリティ証明書109に対してセキュリティ保証局2が署名を行うことにより、セキュリティ保証局2が実施していたセキュリティ証明書の発行処理がサーバ3側に移るため、セキュリティ保証局2が多数のサーバを管理する場合にはその処理負荷を軽減することができる。
【0155】
また、本実施形態の他の変形例によれば、セキュリティ保証局2とサーバ3との間で行われるセキュリティ証明書の発行のための通信において、通信相手に通知される情報に対して、その情報を識別するタグが付加される。これによって、データに含まれるタグの順番等に依存せずに、情報を判別することができるので、セキュリティ保証局2およびサーバ3が様々な形式やサイズの情報を効率よく交換することができる。
【0156】
また、本実施形態の他の変形例によれば、セキュリティ保証局2は、サーバ3のセキュリティ対策の種別を示すセキュリティ対策情報に対して、自身の公開鍵で暗号化を施して暗号データを生成し、その暗号データをセキュリティ証明書に付加する。セキュリティ保証局2は、クライアント4からセキュリティ証明書の有効性の確認を要求された場合に、セキュリティ証明書に付加された暗号データを自身の秘密鍵で復号化することによって得たセキュリティ対策情報に基づいて、セキュリティ証明書の有効性を判断する。これによって、セキュリティ保証局2は、膨大な数のセキュリティ証明書の個々のシリアル番号を管理する必要がなくなるので、セキュリティ保証局2において必要な記録容量を削減し、セキュリティ保証局2の管理コストを低減することができる。さらに、サーバ3のセキュリティ対策情報が暗号化されてセキュリティ証明書に付加されているので、サーバ3のセキュリティ対策情報が漏洩する危険性を低減することができる。
【0157】
また、本実施形態の他の変形例によれば、セキュリティ保証局2は、同一のセキュリティ対策種別を有する複数のサーバに対して、同一のシリアル番号を有するセキュリティ証明書を発行する。換言すると、セキュリティ保証局2は、セキュリティ対策種別ごとに異なるシリアル番号をセキュリティ証明書に付与する。セキュリティ保証局2は、シリアル番号とセキュリティ対策種別、ならびに有効性(失効状態であるかどうか)を示す情報が関連付けられた失効情報テーブルと、セキュリティ証明書に付加されたシリアル番号とに基づいて、セキュリティ証明書の失効状態を判断する。これによって、セキュリティ証明書の有効性の判断に係るセキュリティ保証局2の負荷を軽減することができる。
【0158】
また、本実施形態の他の変形例によれば、TPMやスマートカード等のセキュリティチップをサーバ3に実装し、セキュリティチップ自体に内部監査モジュール39の処理回路を設ける、あるいはセキュリティチップに内部監査モジュール39のハッシュ値を格納することによって、内部監査モジュール39の改竄を防止し、サーバ3のセキュリティレベルをより確実に確認および保証することができる。
【0159】
以上、図面を参照して本発明の実施形態について詳述してきたが、具体的な構成はこれらの実施の形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計変更等も含まれる。
【図面の簡単な説明】
【0160】
【図1】本発明の一実施形態による通信システムの構成を示すブロック図である。
【図2】同実施形態によるセキュリティ保証局の構成を示すブロック図である。
【図3】同実施形態によるサーバの構成を示すブロック図である。
【図4】同実施形態における属性証明書の内容を確認するための表示を示す参考図である。
【図5】同実施形態の変形例による通信システムの構成を示すブロック図である。
【図6】同実施形態の他の変形例による通信システムの構成を示すブロック図である。
【図7】同実施形態の他の変形例における通信シーケンスを示すシーケンス図である。
【図8】同実施形態の他の変形例における通信シーケンスを示すシーケンス図である。
【図9】同実施形態の他の変形例におけるパケットの内容を示す参考図である。
【図10】同実施形態の他の変形例におけるパケットの内容を示す参考図である。
【図11】同実施形態の他の変形例におけるパケットの内容を示す参考図である。
【図12】同実施形態の他の変形例におけるパケットの内容を示す参考図である。
【図13】同実施形態の他の変形例におけるパケットの内容を示す参考図である。
【図14】同実施形態の他の変形例における通信シーケンスを示すシーケンス図である。
【図15】同実施形態の他の変形例におけるパケットの内容を示す参考図である。
【図16】同実施形態の他の変形例における通信シーケンスを示すシーケンス図である。
【図17】同実施形態の他の変形例におけるパケットの内容を示す参考図である。
【図18】同実施形態の他の変形例における失効情報テーブルの内容を示す参考図である。
【図19】同実施形態の他の変形例における内部監査モジュールの耐タンパ化を説明するための参考図である。
【図20】同実施形態の他の変形例における守るべき情報と守られる情報を説明するための参考図である。
【図21】同実施形態の他の変形例における通信システムの構成を示すブロック図である。
【図22】従来の公開鍵証明書および属性証明書のデータ構造を示す参考図である。
【図23】従来の認証局および属性認証局による公開鍵証明書および属性証明書の発行・指定関係を示す参考図である。
【図24】従来の失効証明書リストのデータ構造を示す参考図である。
【図25】従来のIDSの構成を示すブロック図である。
【符号の説明】
【0161】
1・・・認証局、2・・・セキュリティ保証局、3,13・・・サーバ、4・・・クライアント、5・・・IDS・VDSベンダ、6・・・属性認証局、7・・・端末、8,32・・・IDS、9・・・セキュリティGW、10・・・インターネット、11a,11b・・・ネットワーク、12・・・各種端末、21,31・・・通信部、22・・・IDS・VDSベンダからの情報取得部、23・・・サーバとの通信制御部、24・・・クライアントとの通信制御部、25・・・サーバ認証部、26・・・サーバへのIDS・VDSパターンファイル適用部、27・・・属性証明書発行部、28,38・・・記憶部、29・・・失効証明書管理部、33・・・VDS、34・・・クライアント通信制御部、35・・・クライアントからのセッション受付部、36・・・IDS/VDSの起動監視部、37・・・SCAとの通信制御部、39・・・内部監査モジュール、40・・・通信モジュール、41・・・署名検証部、81・・・パケット取得部、82・・・攻撃検査部
【技術分野】
【0001】
本発明は、通信相手の安全レベルを保証することを図った通信システムおよび安全性保証装置に関する。
【背景技術】
【0002】
PKI(Public Key Infrastructure:公開鍵基盤)は、既存のインターネットにおける通信相手を認証するための基盤技術であり(例えば非特許文献1参照)、社会的に信頼されているCA(Certificate Authority:認証局)が、公開鍵と秘密鍵のペアを作成したホストの公開鍵に対して「確かに該当ホストが公開鍵を作成した」ことを保証する技術である。PKIにおいては、通信相手(ここではサーバと呼ぶ)が生成した公開鍵と秘密鍵のペアのうち公開鍵に対して、社会的に信頼されているCAが、自身の秘密鍵を使ってデジタル署名(証明書の発行)を施した公開鍵証明書(PKC:Public Key Certificate)を発行している。通信の受け側(ここではクライアントと呼ぶ)は、通信相手から送られてきたPKCを確認するために、CAの公開鍵を用いてPKCのデジタル署名を検証し、通信相手の本人性(識別性)を認証している。
【0003】
CAは、公開鍵と秘密鍵のペアを作成したサーバから公開鍵を受け取り、サーバの身元をオフラインで確認した後に、その公開鍵を含む証明書を発行する。ここで発行とは、サーバの公開鍵とその付随情報を含めた情報の全体に、CA自身の秘密鍵でデジタル署名を施す処理である。代表的な証明書として、X.509証明書がある(例えば非特許文献2〜4参照)。
【0004】
この証明書には、本人性の証明用のPKCと、PKCにリンク付けされた属性証明用の属性証明書(AC:Attribute Certificate)とがある(図22参照)。PKCやACの拡張領域には、公開鍵所有者に付随する情報や証明書の利用目的などの属性情報を付加することが可能である。ただし、頻繁に属性が更新される場合には、PKCの更新コストが問題になるため、ACを利用することになる。PKCは、信頼されるCAに発行・管理されるが、ACはローカルな属性認証局(AA:Attribute Authority)で発行・管理してもよい。
【0005】
図23は、CAおよびAAによるPKCおよびACの発行・指定関係を示している。認証局(CA)1は、端末(EE)7からの要求に応じて、端末7の公開鍵証明書(PKC)100を発行する。属性認証局(AA)6は、端末7の公開鍵証明書100にリンク付けされた属性証明書(AC)101を発行する。
【0006】
PKCの署名が正しく、有効期限内であっても、何らかの理由により、PKCを無効化しなければならないことがある。無効化するPKCは失効証明書リスト(CRL: Certificate Revocation List)に記録される。このフォーマットを図24に示す。
【0007】
通信システムにおけるウィルス等の攻撃に対して、通信システムの安全性を向上させるためのシステムとして、侵入検知システム(IDS:Intrusion Detection System)およびウィルス検知システム(VDS:Virus Detection System)がある。IDSは、ネットワーク上を流れるパケットやホスト上のログファイルを監視して、攻撃パターンファイルと一致するパケットやログファイルを検知するとアラームを発するシステムである。図25は、ネットワーク上のパケットを監視して、不正な行為を監視するネットワーク型IDSのモデルを示している(例えば非特許文献5参照)。
【0008】
図において、IDS8はネットワーク11aおよび11b間を流れるパケット200を監視する。IDS8において、パケット取得部81は、パケット200を取得し、攻撃検査部82へ出力する。攻撃検査部82は、攻撃パターンファイル300に記録されている攻撃パターンに基づいて、取得されたパケットが攻撃によるものであるかどうか判断し、攻撃によるものであると判断した場合には、ログ301に記録すると共に、アラームを発する等の処理を行う。
【0009】
一方、VDSは、ホスト上のファイルもしくはネットワーク上で送受信されるファイルの中に、コンピュータウイルスのパターンファイルと一致するコードを検知するとアラームを出力するシステムである(例えば非特許文献6参照)。一般にVDSは、クライアントホストやサーバ、ネットワークGW(ゲートウェイ)に設置される。
【非特許文献1】カーライル・アダムス、スティーブ・ロイド著,鈴木優一訳,「PKI 公開鍵インフラストラクチャの概念、標準、展開」,ピアソン・エデュケーション,2000年7月。
【非特許文献2】「Information Technology - Open Systems Interconnection - The Directory Authentication Framework.」,ITU-T Recommendation X.509,June 1997,(equivalent to ISO/IEC 9594-8,1997)
【非特許文献3】「Internet X.509 Public Key Infrastructure Certificate and CRL Profile」,IETF,RFC2459,1999.
【非特許文献4】「An Internet Attribute Certificate Profile for Authorization」,IETF,RFC3281,2002
【非特許文献5】武田圭史、磯崎宏,「ネットワーク侵入検知」,ソフトバンク パブリッシング,2000年6月
【非特許文献6】アトミックドロップ,「まるごと図解 最新 コンピュータウイルスがわかる」,技術評論社,2000年10月
【発明の開示】
【発明が解決しようとする課題】
【0010】
しかし、従来の通信システムにおいては、通信相手の本人性を認証することはできるものの、その通信の安全性レベルを保証するものではなかった。従って、通信相手のサーバが悪意のサーバや、セキュリティ対策を図っていないサーバであった場合、クライアント側が攻撃されることもあるという問題点があった。
【0011】
本発明は、上述した問題点に鑑みてなされたものであって、通信相手がセキュリティ対策を施していることを保証することができる通信システムおよび安全性保証装置を提供することを目的とする。
【課題を解決するための手段】
【0012】
本発明は、上記の課題を解決するためになされたもので、通信元装置と、該通信元装置と通信を行う通信相手装置と、前記通信相手装置の通信上の安全性を保証する安全性保証装置とを具備する通信システムであって、前記通信相手装置は、自身の通信上の安全性を通知するための通知情報を前記安全性保証装置へ送信し、前記安全性保証装置は、前記通知情報を受信し、該通知情報に基づいて前記通信相手装置の通信上の安全性を検証し、該通信上の安全性を確認した場合に、該通信上の安全性を証明する安全性証明情報を生成して前記通信相手装置へ送信し、前記通信相手装置は、前記安全性証明情報を受信し、前記通信元装置からの接続要求に応じて前記安全性証明情報を前記通信元装置へ送信し、前記通信元装置は、前記通信相手装置に対する接続要求の後、前記通信相手装置から前記安全性証明情報を受信し、該安全性証明情報に基づいて前記通信相手装置の通信上の安全性を検証することを特徴とする通信システムである。
【0013】
本発明は、通信元装置と、該通信元装置と通信を行う通信相手装置と、前記通信相手装置の通信上の安全性を保証する安全性保証装置とを具備する通信システムであって、前記通信相手装置は、自身の通信上の安全性を証明する安全性証明情報を前記安全性保証装置へ送信し、前記安全性保証装置は、前記安全性証明情報を受信し、該安全性証明情報に対して署名情報を付加して、前記安全性証明情報を前記通信相手装置へ送信し、前記通信相手装置は、前記安全性証明情報を受信し、前記通信元装置からの接続要求に応じて、前記署名情報の付加された前記安全性証明情報を前記通信元装置へ送信し、前記通信元装置は、前記通信相手装置に対する接続要求の後、前記通信相手装置から前記安全性証明情報を受信し、該安全性証明情報、および該安全性証明情報に付加された前記署名情報に基づいて前記通信相手装置の通信上の安全性を検証することを特徴とする通信システムである。
【0014】
本発明は、通信元装置と、該通信元装置からの接続要求に応じて、該通信元装置と通信を行う通信相手装置と、前記通信相手装置の通信上の安全性を保証する安全性保証装置とを具備する通信システムにおける安全性保証装置であって、前記通信相手装置によって送信された、該通信相手装置の通信上の安全性を通知する通知情報を受信する受信手段と、前記通知情報に基づいて前記通信相手装置の通信上の安全性を検証する検証手段と、該検証手段によって前記通信相手装置の通信上の安全性が確認された場合に、該通信上の安全性を証明する安全性証明情報を生成する証明情報生成手段と、該安全性証明情報を前記通信相手装置へ送信する送信手段とを具備することを特徴とする安全性保証装置である。
【0015】
本発明は、通信元装置と、該通信元装置からの接続要求に応じて、該通信元装置と通信を行う通信相手装置と、前記通信相手装置の通信上の安全性を保証する安全性保証装置とを具備する通信システムにおける安全性保証装置であって、前記通信相手装置によって送信された、該通信相手装置の通信上の安全性を通知する安全性証明情報を受信する受信手段と、前記安全性証明情報に対して署名情報を付加する署名情報付加手段と、該署名情報が付加された前記安全性証明情報を前記通信相手装置へ送信する送信手段とを具備することを特徴とする安全性保証装置である。
【発明の効果】
【0016】
本発明によれば、安全性保証装置が通信相手装置の通信上の安全性を証明するようにしたので、通信相手がセキュリティ対策を施していることを保証することができるという効果が得られる。
【発明を実施するための最良の形態】
【0017】
以下、図面を参照し、本発明を実施するための最良の形態について説明する。図1は、本発明の一実施形態による通信システムの構成を示すブロック図である。この通信システムは、サーバ・クライアント通信におけるサーバの本人性の認証を行うと共に、その通信の安全性のレベル(セキュリティレベル)を保証するシステムである。図において、認証局(CA)1は既存の認証局であり、サーバ3からのPKC(公開鍵証明書)の発行要求に応じて、サーバ3の公開鍵についてのPKC102(識別性情報)を発行する。セキュリティ保証局(SCA)2(安全性保証装置)は、サーバ3のセキュリティレベルを保証するためのAC(属性証明書)105を発行する。このセキュリティ保証局2は、既存の認証局1によって認証され、自身の公開鍵についてのPKCを発行されており、社会的に信頼されている第三者的な立場の機関とする。
【0018】
サーバ3(通信相手装置)は本人性および安全性の検証の対象となるサーバであり、セキュリティ対策システムの一種であるIDS(侵入検知システム)32およびVDS(ウィルス検知システム)33を備えている。クライアント4(通信元装置)はサーバ3に接続してサービスを受けようとしている端末装置である。このクライアント4は、サーバ3に対して発行されたPKC102およびAC105に基づいて、サーバ3の本人性(識別性)およびセキュリティレベル(通信上の安全性)の検証を行う署名検証部41を備えている。なお、認証局1、セキュリティ保証局2、サーバ3、およびクライアント4は図示せぬインターネットを介して相互に接続されている。
【0019】
図2は、セキュリティ保証局2の構成を示すブロック図である。以下、図中の各構成について説明する。通信部21は、インターネット10を介してサーバ3、クライアント4、およびIDS・VDSベンダ5等の他の通信装置と情報の送受信を行う。IDS・VDSベンダからの情報取得部22は、通信部21を介してIDS・VDSベンダ5から最新のIDS/VDSのパターンファイルを取得し、記憶部28に格納する。IDS/VDSのパターンファイルには、IDSおよびVDSが検知すべき攻撃やウィルスのパターンが予め記録されている。
【0020】
サーバとの通信制御部23はサーバ3との通信を制御する。クライアントとの通信制御部24はクライアント4との通信を制御する。サーバ認証部25はサーバ3の本人性およびセキュリティレベルの認証を行う。サーバへのIDS・VDSパターンファイル適用部26は、サーバ3に仕掛ける擬似攻撃を生成するが、詳細については後述する。属性証明書発行部27は、サーバ認証部25によってサーバ3の本人性およびセキュリティレベルが確認された場合に、属性証明書(AC)を発行する。記憶部28は、サーバ3に対するACの発行に必要な情報や、自身の公開鍵・秘密鍵に関する情報、発行したAC等を記憶する。
【0021】
図3は、サーバ3の構成を示すブロック図である。以下、図中の各構成について説明する。通信部31は、インターネット10を介して認証局1、セキュリティ保証局2、およびクライアント4等の他の通信装置と情報の送受信を行う。クライアント通信制御部34はクライアント4との通信を制御する。クライアントからのセッション受付部35は、クライアント4からの接続要求があった場合に、クライアント4との通信にセッションを設定し、そのセッションを管理する。
【0022】
IDS/VDSの起動監視部36はpsコマンドやlsコマンドを用いてIDS32およびVDS33の起動を確認し、それらの起動状態に関する情報を取得するが、詳細については後述する。SCAとの通信制御部37はセキュリティ保証局2との通信を制御する。記憶部38は、自身の公開鍵・秘密鍵に関する情報や、認証局1によって発行されたPKC、セキュリティ保証局2によって発行されたAC、IDS/VDSの運用に関する情報(ログ、パターンファイル)等の情報を記憶する。
【0023】
次に、本実施形態による通信システムの動作について説明する。前提として、セキュリティ保証局2は自身の公開鍵と秘密鍵のペアを作成し、認証局1からPKCを発行されているものとする。また、セキュリティ保証局2はIDS・VDSベンダ5からIDS/VDSの最新のパターンファイルを取得しているものとする。サーバ3は自身の公開鍵と秘密鍵のペアを生成し(ステップS1)、生成した公開鍵の正当性を保証するデジタル署名を依頼するためのPKC発行要求情報を生成し、認証局1へ送信する(ステップS2)。このPKC発行要求情報には、サーバ3の公開鍵が含まれている。
【0024】
認証局1はPKC発行要求情報を受信し、サーバ3の身元の確認後、PKC発行要求情報に付加されたサーバ3の公開鍵を含むサーバ3の情報に対して、自身の秘密鍵によりデジタル署名を施した署名情報を含むPKC102を生成し、サーバ3へ送信する(ステップS3)。このPKC102はサーバ3の通信部31によって受信され、IDS32を介して記憶部38に格納される。一方、セキュリティ保証局2においてサーバとの通信制御部23は記憶部28から最新のIDS/VDSのパターンファイルを読み出し、通信部21を介して、IDS/VDSパターンファイル103としてサーバ3へ送信する(ステップS4)。
【0025】
サーバ3において通信部31はセキュリティ保証局2からIDS/VDSパターンファイル103を受信し、IDS32へ出力する。IDS32はこのIDS/VDSパターンファイル103を記憶部38に格納する。また、SCAとの通信制御部37は、認証局1によって発行されたPKC102にリンク付けされるACの発行を要求するためのAC発行要求情報を生成し、IDS32および通信部31を介してセキュリティ保証局2へ送信する(ステップS5)。このAC発行要求情報には、サーバ3のPKC102(識別性証明情報)と、ACの発行に必要な情報104(通知情報)とが含まれる。PKC102は、サーバ3がセキュリティ保証局2に対して自身の身元を証明するための情報であり、ACの発行に必要な情報104は、自身のIDS32およびVDS33に関する情報等、自身のセキュリティレベルをセキュリティ保証局2に通知するための情報である。ACの発行に必要な情報104はPKC102の拡張領域に格納されていてもよい。
【0026】
セキュリティ保証局2はサーバ3からAC発行要求情報を受信し、PKC102に基づいてサーバ3を認証すると共に、ACの発行に必要な情報104に基づいてサーバ3のセキュリティレベルの認証を行い、両方の認証に成功した場合に、PKC102に基づいてAC105を生成し、サーバ3へ送信する(ステップS6)。以下、ステップS6におけるセキュリティ保証局2の動作を詳述する。
【0027】
サーバとの通信制御部23は、通信部21を介してサーバ3からAC発行要求情報を受信し、サーバ認証部25へ出力する。サーバ認証部25は、AC発行要求情報に付加されたPKC102に基づいて、サーバ3の身元を検証する。具体的には、サーバ認証部25は、PKC102に付加されている、認証局1の秘密鍵によって暗号化されたデジタル署名を認証局1の公開鍵で復号化し、デジタル署名の復号化によって得られた公開鍵等のデータと、PKC102に付加されている公開鍵等の非暗号化データとを比較し、両者が一致した場合に、サーバ3の身元の認証に成功したとする。
【0028】
また、サーバ認証部25は、AC発行要求情報に付加されたACの発行に必要な情報104に基づいて、サーバ3のセキュリティレベルを検証する。サーバ認証部25は、ACの発行に必要な情報104に含まれる情報から、サーバ3がセキュリティ対策を施しているかどうか知ることができ、さらに、後述する各手法により、サーバ3のセキュリティレベルをより正しく知ることができる。サーバ3の身元の認証およびセキュリティレベルの認証に成功した場合、サーバ認証部25は、属性証明書発行部27に対してACの発行を指示する。指示を受けた属性証明書発行部27は、PKC102に基づいてACを生成し、記憶部28に格納する。このACには、セキュリティ保証局2の秘密鍵によるデジタル書名が付与されており、また、拡張領域にはサーバ3のセキュリティレベルを証明する情報(安全性証明情報)が格納されている。属性証明書発行部27は、サーバ認証部25を介してACをサーバとの通信制御部23へ出力し、サーバとの通信制御部23は、通信部21を介して、このACをAC105としてサーバ3へ送信する(ステップS6)。
【0029】
続いて、クライアント4は、サーバ3との通信を開始するために、サーバ3に対する接続要求と、PKC102およびAC105の受信要求とを示す接続要求情報をサーバ3へ送信する(ステップS7)。サーバ3において通信部31は接続要求情報を受信し、IDS32を介してクライアントからのセッション受付部35へ出力する。クライアントからのセッション受付部35は、接続要求情報に基づいてクライアント4とのセッションを生成すると共に、PKC102およびAC105の送信をクライアント制御部34に指示する。指示を受けたクライアント制御部34は記憶部38からPKC102およびAC105を読み出し、IDS32を介して通信部31へ出力する。通信部31はPKC102およびAC105をクライアント4へ送信する(ステップS8)。
【0030】
クライアント4はサーバ3からPKC102およびAC105を受信し、自身が認証局1およびセキュリティ保証局2の公開鍵を所持している場合には、PKC102およびAC105のデジタル署名を検証する(ステップS9)。すなわち、クライアント4の署名検証部41は、PKC102に付加されている、認証局1の秘密鍵によって暗号化されたデジタル署名を認証局1の公開鍵で復号化し、デジタル署名の復号化によって得られた公開鍵等のデータと、PKC102に付加されている公開鍵等の非暗号化データとを比較し、両者が一致した場合に、サーバ3の身元の認証に成功したとする。
【0031】
また、署名検証部41は、AC105に付加されている、セキュリティ保証局2の秘密鍵によって暗号化されたデジタル署名をセキュリティ保証局2の公開鍵で復号化し、デジタル署名の復号化によって得られた公開鍵等のデータと、AC105に付加されている公開鍵等の非暗号化データとを比較し、両者が一致した場合に、サーバ3のセキュリティレベルの認証に成功したとする。
【0032】
一方、クライアント4が認証局1およびセキュリティ保証局2の少なくとも一方の公開鍵を予め所持していない場合には、以下のようになる。クライアント4が認証局1の公開鍵を予め所持していない場合には、クライアント4は、認証局1に対してPKCを要求する(ステップS10a)。PKCを要求された認証局1は、自身の公開鍵についてのPKC106をクライアント4へ送信する(ステップS11a)。クライアント4はPKC106を受信し、署名検証部41は、PKC106を用いてPKC102のデジタル署名を検証する。
【0033】
また、クライアント4がセキュリティ保証局2の公開鍵を予め所持していない場合には、クライアント4は、セキュリティ保証局2に対してPKCを要求する(ステップS10b)。PKCを要求されたセキュリティ保証局2は、自身の公開鍵についてのPKC107をクライアント4へ送信する(ステップS11b)。クライアント4はPKC107を受信し、署名検証部41は、PKC107を用いてAC105のデジタル署名を検証する。
【0034】
上記の検証の結果、サーバ3のPKC102およびAC105のデジタル署名の有効性が確認できた場合、サーバ3およびクライアント4は以後の通信を開始する。また、サーバ3のIDS32およびVDS33は、サーバ3側の通信を監視する(ステップS12)。PKC102およびAC105のデジタル署名の有効性が確認できた場合には、クライアント4は、AC105に関する概要情報(図4(a)参照)や詳細情報(図4(b)参照)を図示せぬ表示部に表示する。これにより、ユーザはサーバ3のセキュリティレベルを視覚的に確認することができる。また、図4(a)に示されるように、その表示に基づいて、ユーザに対して通信の開始の可否を選択させるようにしてもよい。
【0035】
次に、セキュリティ保証局2によるサーバ3のセキュリティレベルの認証について説明する。セキュリティ保証局2によって発行されるAC105の拡張フィールドには、セキュリティを保証する以下の情報のうちいくつかが付加される。ただし、これは、サーバ3が厳密な情報を提供する場合である。
・証明書の発行先情報(サーバ3を特定する情報)
・証明書の発行者情報(セキュリティ保証局2を特定する情報)
・証明書の発行日(証明書が生成された時を特定する情報)
・証明書の有効期限
・証明書を作成するためのアルゴリズムに関する諸情報
・IDSやVDSにより通信を監視している事実
・IDSやVDSに関するツール名もしくはツールID(IDSやVDSを特定する情報)
・IDSやVDSに関するバージョン番号(IDSやVDSを特定する情報)
・IDSやVDSの最新適用パターンファイルID(IDSやVDSを特定する情報)
・IDSやVDSの最新適用パターンファイル発行日(IDSやVDSを特定する情報)
・監視ポリシ
【0036】
サーバ3において複数のセキュリティツールが適用されている場合には、各セキュリティツールに関しての複数の情報が記載される。また、IDSやVDSで、通信をどのように監視するのかといったポリシ自体もしくはポリシIDが記載される。ここでポリシとは、IPスキャン攻撃は検知するが、ポートスキャン攻撃は検知しないといったパターンファイルの利用方法である。
【0037】
上記のような厳密な情報は、場合によってはセキュリティ情報の漏洩に繋がる場合もある。例えば、脆弱性を持つIDSやVDSを利用している場合や、パターンファイルの適用の遅れ等は、監視システムからの回避情報を侵入者に知らせることにもなる。よって、下記の情報のみがAC105の拡張フィールドに格納され、セキュリティ保証局2が保証するレベルのみをクライアント4に通知してもよい。
・証明書の発行先情報
・証明書の発行者情報
・証明書の発行日
・証明書の有効期限
・証明書を作成するためのアルゴリズムに関する諸情報
・IDSやVDSにより通信を監視している事実
【0038】
上記の情報は、セキュリティ保証局2が独自に決定するか、またはサーバ3からセキュリティ保証局2へ送信されるACの発行に必要な情報104に基づいてセキュリティ保証局2が生成する。例えば、証明書の発行先情報は、サーバ3から取得したPKC102に基づいてセキュリティ保証局2が生成する。また、証明書の発行者情報、証明書の発行日、証明書の有効期限、証明書を作成するためのアルゴリズムに関する諸情報もセキュリティ保証局2が決定する。その他、IDSやVDSにより通信を監視している事実、IDSやVDSに関するツール名もしくはツールID等の情報は、サーバ3から取得したACの発行に必要な情報104に基づいて、セキュリティ保証局2が生成する。
【0039】
セキュリティ保証局2は、サーバ3の本人性の認証に成功した場合であって、ACの発行に最低限必要な情報として、IDSやVDSにより通信を監視している事実を示す情報がACの発行に必要な情報104に格納されていた場合に、その情報に基づいて、サーバ3がセキュリティ対策を行っていることを信用し、AC105を生成してサーバ3へ送信してもよいが、サーバ3が悪意のサーバである可能性もあるため、サーバ3のセキュリティレベルをより確実に保証する手法が必要である。以下、このための手法について説明する。
【0040】
(1)インターネットサービスプロバイダ(ISP)等によるサーバシステムの管理
サーバ3や、サーバ3の処理を代行する後述の外部装置をISPやセキュリティ保証局2等の施設内で管理している環境では、サーバ3におけるIDSやVDSの動作状況をISPやセキュリティ保証局2の運用者が直接確認する。
【0041】
(2)サーバシステム自体の耐タンパ性の利用
ISPやセキュリティ保証局2が、サーバ3の処理を代行する後述するような外部装置を提供する場合に、その装置の耐タンパ性(不正アクセス・不正改竄防止機能)を担保にする。例えば、サーバ3の処理を代行する外部装置には、その装置が開封されただけで、その装置の動作を規定するソフトウェアが記録されているメモリおよびディスクや、その装置の動作を実現する回路自体等が物理的に壊れて、使用不能となってしまう仕組みを設ける。これにより、外部装置の内部構成を保護し、偽造を防ぐことができる。
【0042】
また、SSH通信による両方向の認証を利用して、サーバ3の処理を代行する外部装置またはサーバ3自体に、ISPやセキュリティ保証局2からしかIDSやVDSを遠隔操作することができない仕組みを設ける。以下、この場合について詳述する。SSHによる両方向の認証には、公開鍵暗号認証方式およびパスワード認証方式の2種類がある。以下、一般に用いられている「発信元」「着信元」モデルについて説明する。
【0043】
公開鍵暗号認証方式においては、発信元は自身の持つ秘密鍵によって署名した電子署名データを着信先に送信する。着信先は、発信元の公開鍵により電子署名データを復号化し、その電子署名の正当性を検証する。検証には、既存の認証局が発行したPKCを利用する。セキュリティ保証局2とサーバ3との間の両方向でお互いにPKCを交換し合うことにより、お互いを認証し合うことができる。一方、パスワード認証方式においては、予め発信元と着信先の両者で取り決めておいたパスワードを送受信することにより、認証を行う。これは、広く一般で利用されている方式であるが、SSH通信の場合、このパスワードは暗号によって保護されて送受信される。この場合、セキュリティ保証局2とサーバ3との間で予めパスワードを取り決めておく。なお、通信セッションの開始はセキュリティ保証局2およびサーバ3のどちらからでもよい。
【0044】
上記の認証の後、セキュリティ保証局2とサーバ3は暗号通信(例えば秘密鍵暗号方式)を行う。この暗号通信において、セキュリティ保証局2は、サーバ3の各部を制御し、操作するための操作情報をサーバ3へ送信してサーバ3を遠隔操作する。サーバ3は、操作情報に基づいて、IDS32およびVDS33に関する情報を生成し、セキュリティ保証局2へ送信する。セキュリティ保証局2は、その情報を受信し、ACの発行に必要な情報104の代わりに用いて、サーバ3のセキュリティレベルの検証を行う。
【0045】
また、上記の動作は、セキュリティ保証局2がサーバ3を遠隔操作するのではなく、サーバ3が主体的に動作することにより行ってもよい。すなわち、サーバ3はセキュリティ保証局2との両方向の認証後、IDS32およびVDS33に関する情報を生成し、セキュリティ保証局2へ送信する。セキュリティ保証局2は、その情報を受信し、ACの発行に必要な情報104の代わりに用いて、サーバ3のセキュリティレベルの検証を行う。
【0046】
(3)サーバ側での監視処理の起動確認
サーバ3上にIDS32やVDS33の状態を確認する専用の機能を予め用意する。Linux OSの場合には、「ps」コマンドにより、起動プロセスの情報を得る機能がある。サーバ3上でpsコマンドを実行することにより得られた情報の中から、IDSプロセス(またはVDSプロセス)の名前、IDSプロセス(またはVDSプロセス)のサイズを取得して、それらが正しい情報であれば(サーバ3がセキュリティ保証局2へ通知した情報と同じであれば)、起動していると判断する。具体的なコマンドは以下の通りである。
> ps -ef | grep プロセス名
【0047】
また、適用されているパターンファイルが最新のものであることを確認するために、サーバ3上で「ls」 コマンドを実行することにより得られた情報の中から、パターンファイルの名前、パターンファイルのサイズ、パターンファイルの日付(更新日)を取得して、最新のパターンファイルを適用したことが分かる情報を得る。具体的なコマンドは以下の通りである。
> ls -l ディレクトリ名/ファイル名
【0048】
サーバ3は、上記の2つのコマンドを実行することにより取得した、IDS32またはVDS33の状態を示す状態情報をまとめてセキュリティ保証局2へ送信する。ただし、このとき悪意のサーバは、情報を偽装する恐れがある。これを防止するために、上記の2つの情報収集処理と、これをセキュリティ保証局2に送信する処理を一つのプログラムとして作成しておき、このプログラムに対してソフトウェアの難読化を実施して、実行モジュールの改竄を防止する。
【0049】
難読化とは、整然と書かれているプログラムの構造を変形させることにより、実行結果は変わらないものの、その解析を困難にする技術である。具体的には、
・実行に影響を与えない不要なコードを追加する。
・命令コードを別の等価なコードに置き換える。
・一つの計算を複数の計算に分割する。
・一つの機能を持ったモジュール(関数、サブルーチン)を複数のモジュールに分割する。
・同一の処理を行うモジュールを複数用意して冗長化する。
等の操作をそのプログラムに対して行う。難読化のタイミングとしては二種類あり、一つは、ソースコードを難読化してからコンパイルして実行コードを得るというものであり、もう一つは、ソースコードをコンパイルしてから難読化して実行コードを得るというものである。
【0050】
上記の起動確認を行う場合、サーバ3のIDS/VDSの起動監視部36は、psコマンドまたはlsコマンドに相当する処理を実行し、IDS32またはVDS33(あるいは両方)について、上記の起動プロセスまたはパターンファイルについての状態情報を生成し、IDS32を介して通信部31へ出力する。通信部31は状態情報をセキュリティ保証局2へ送信する。
【0051】
セキュリティ保証局2の通信部21は状態情報を受信し、サーバとの通信制御部23を介してサーバ認証部25へ出力する。サーバ認証部25は、サーバ3のセキュリティレベルを以下のように認証する。サーバ認証部25は、サーバ3から受信されたACの発行に必要な情報104と状態情報とを比較し、状態情報が示すIDSプロセスの名前、IDSプロセスのサイズ、パターンファイルの名前、パターンファイルのサイズ、およびパターンファイルの日付が、ACの発行に必要な情報104に含まれるそれらの内容と一致するかどうか検証する。
【0052】
状態情報の内容がACの発行に必要な情報104に含まれる情報の内容と一致した場合、サーバ認証部25はサーバ3のセキュリティレベルを確認することができたとし、認証を終了する。これにより、セキュリティ保証局2は、ACの発行に必要な情報104としてサーバ3から通知された情報が、改竄できない実行モジュールに基づいて得た状態情報の内容と一致する正しい情報であることを知ることができ、サーバ3のセキュリティレベルをより確実に確認および保証することができる。なお、上記の場合、サーバ3がセキュリティ保証局2へ送信するACの発行に必要な情報104には、IDS32またはVDS33の状態情報が含まれている必要がある。
【0053】
(3)パターンファイルの適用の外部からの確認
セキュリティ保証局2が、サーバ3に対して擬似攻撃を仕掛け、サーバ3のIDS32またはVDS33によって出力されたログを取得し、そのログに基づいて、サーバ3が最新のパターンファイルを適用しているかどうか確認する。この場合、サーバへのIDS・VDSパターンファイル適用部26は記憶部28から最新のパターンファイル(パターン情報)を読み出し、更新された攻撃パターン(シグネチャ)を認識する。更新された攻撃パターンの認識において、サーバへのIDS・VDSパターンファイル適用部26は記憶部28から最新のパターンファイルおよびその一つ前のバージョンのパターンファイルを読み出し、両者の内容を比較し、最新のパターンファイルのみに含まれるパターンを、更新された攻撃パターンとして認識してもよい。
【0054】
続いて、サーバへのIDS・VDSパターンファイル適用部26は、更新された攻撃パターンに基づいた攻撃パケットを連続的に生成し、サーバ認証部25を介してサーバとの通信制御部23へ出力する。サーバとの通信制御部23は攻撃パケットを連続的にサーバ3へ送信する。サーバ3の通信部31は攻撃パケットを受信し、IDS32へ出力する。IDS32は記憶部38から最新のパターンファイルを読み出し、そのパターンファイルに基づいてパケットを監視し、最新の攻撃パターンと一致するパケットを検知した場合には、その攻撃パターン名(シグネチャ名)、送信元IP、時刻情報等をログ(攻撃検知情報)に記録する。
【0055】
IDS32は所定のタイミングでログを読み出し、通信部31へ出力する。通信部31はログをセキュリティ保証局2へ送信する。セキュリティ保証局2の通信部21はログを受信し、サーバとの通信制御部23を介してサーバ認証部25へ出力する。サーバ認証部25は、更新された攻撃パターンがログに記録されているかどうか検証し、記録されていた場合には、サーバ3のセキュリティレベルを確認することができたとし、認証を終了する。これにより、セキュリティ保証局2は、サーバ3が最新のパターンファイルに基づいたセキュリティ対策を行っているかどうか確認することができ、サーバ3のセキュリティレベルをより確実に確認および保証することができる。
【0056】
なお、セキュリティ保証局2が、ウィルスに関しての最新のパターンファイルに基づいて、ウィルスに感染した攻撃パケットを生成し、サーバ3へ送信してもよい。この場合、サーバ3においては、VDS33が、最新のパターンファイルに基づいて、ウィルスによるパケットを検出し、ログに記録する。セキュリティ保証局2は、上記と同様にしてこのログを取得し、最新のパターンファイルおよびログに基づいて、サーバ3のセキュリティレベルを認証する。
【0057】
次に、PKCおよびACの発行処理の他の形態について説明する。既存の認証局1がセキュリティ保証局2の役割を担うこともでき、その場合には、PKCとACとの両方を認証局1が発行する。逆に、既存の認証局1の役割をセキュリティ保証局2が代行することもでき、その場合には、PKCとACとの両方をセキュリティ保証局2が発行する。また、既存の認証局1はPKCを発行し、IDS/VDSベンダーがACを発行する場合も考えられる。
【0058】
次に、IDSやVDSとそのパターンファイルの管理および更新の形態ついて説明する。IDSやVDSの選定からパターンファイルの適用等の運用・管理に至るまで、サーバ管理者が独自に行ってもよいし、IDSやVDSの選定はサーバ管理者が行い、そのパターンファイルの適用に関しては、セキュリティ保証局2もしくはIDSやVDSを提供するベンダーが代行してもよい。あるいは、IDSやVDSの選定からパターンファイルの適用までセキュリティ保証局2もしくは、IDSやVDSを提供するベンダーが代行してもよい。この場合には、セキュリティ保証局2やベンダーは、IDSやVDSが設定されたネットワーク機器(ハードウェアのゲートウェイ等)をサーバ管理者に付与して、サーバ管理者はそれを設置するのみの作業となる。
【0059】
次に、サーバ3が行う各処理の代行について説明する。一般に、サーバを構築するときには、サーバ自体を簡易な構成にすること、余計な処理負荷を掛けないことが望まれている。そこで、
1)公開鍵と秘密鍵の生成処理
2)PKCの発行依頼と発行された証明書の管理
3)IDS/VDSのパターンファイルの更新
4)セキュリティ保証局2に対するACの発行依頼と、発行された証明書の管理
5)IDSやVDSによる通信の監視
6)クライアント4へのPKCとACの提示
の各種処理を、外部装置が代行してもよい。図1においては、サーバ3が上記の1)から6)の全ての処理を実行するとしているが、サーバ3の処理負荷を軽減するために、プロキシ装置、RouterやFirewall等のネットワークゲートウェイ(N−GW)、ホームゲートウェイ(H−GW)等の装置に、1)から6)のいくつか、もしくは全ての処理を代行させてもよい。
【0060】
次に、サーバ3がクライアント4に対してPKC102およびAC105を送信する際に、この動作を行う悪意のサーバを排除する方法について説明する。サーバ3はクライアント4から接続要求を受けるとPKC102およびAC105をクライアント4へ送信する。このとき、悪意のサーバはIDSやVDSを停止しているにも関わらず、AC105を送信することが考えられる。そこで、クライアント4からの接続要求を受けたサーバ3は、psコマンドやlsコマンドを実行して、IDSやVDSが実行されていることや最新のパターンファイルの適用を確認することができた場合にのみAC105をクライアント4へ送信する。psコマンドやlsコマンドによるIDSやVDSの起動確認処理とクライアント4へのAC105の提示処理とを一体化ソフトウェアとして1つのプログラムにまとめておき、この一体化ソフトウェアに対して難読化を実施することにより、悪意の改竄を防止することができる。
【0061】
次に、証明書の無効化処理について説明する。IDSやVDSに関する脆弱性情報が公開された場合や、新たなパターンファイルが出た場合には、以前の状態で発行されたACを無効化しなければならない。無効化のためには、図8のようなCRLを用いることになる。この場合、認証局1やセキュリティ保証局2は、発行したPKCやACに関するCRLを管理しておき、クライアント4から有効性の問い合わせがあったときに回答することになる。
【0062】
なお、クライアント4の署名検証部41が、サーバ3から送信されたPKC102およびAC105に基づいて、サーバ3の本人性およびセキュリティレベルの認証を行う際に、PKC102およびAC105の内容に応じて、サーバ3との通信の受け入れの可否を自動的に判断するようにしてもよい。
【0063】
上述した本実施形態においては、サーバ3がセキュリティ対策システムとしてIDS32およびVDS33を備えているが、Firewallあるいは検疫システムをセキュリティ対策システムとして備えていてもよい。Firewallは、ネットワークや端末の接続点において、許可されていないアクセスを棄却する装置であり、主に、外部ネットワークから内部ネットワークへのアクセスを制限することによって攻撃を防ぐものである。また、検疫システムは、OSやアプリケーションのバージョンおよびパッチの状態を確認して最新の状態を確保するものである。
【0064】
サーバ3がACの発行に必要な情報104をセキュリティ保証局2へ送信する際には、自身が有するOSやアプリケーションのバージョン、パッチの状態、およびPortの設定等を確認し、ACの発行に必要な情報104の中にこれらの情報を格納してセキュリティ保証局2へ送信するようにしてもよい。セキュリティ保証局2は、サーバ3のOSやアプリケーションについての上記の情報に基づいて、サーバ3のセキュリティレベルを検証してもよい。
【0065】
本実施形態においては、既存のPKIを利用して、セキュリティ保証局2がサーバ3のセキュリティレベルと共に本人性の検証を行っているが、サーバ3のセキュリティレベルの検証を行う上ではPKIは必須ではない。したがって、認証局1が設けられていなくてもよく、セキュリティ保証局2とサーバ3との間でPKCの送受信が行われなくてもよい。さらに、本実施形態においては、セキュリティ保証局2が、サーバ3のセキュリティレベルを証明する情報をAC105の拡張領域に格納してサーバ3へ送信しているが、これに限定されず、サーバ3のセキュリティレベルを証明する情報を含む独立したセキュリティ証明書として送信してもよい。また、ACの代わりにPKIの拡張領域に上記の情報を格納してもよく、SPKI(例えば文献「ITU-T,"SPKI Certificate Theory",IETF,RFC2693,1999」参照)において定義される形式の証明書に上記の情報を格納してもよい。
【0066】
次に、本実施形態の変形例について説明する。図5は、本変形例に係る通信システムの構成を示すブロック図である。図5においては認証局1の図示およびPKIに基づいた本人性の認証の図示は省略されている。本変形例においても、本人性の認証を行ってもよいし、行わなくてもよい。サーバ3内に設けられた内部監査モジュール39は、セキュリティ保証局2から外部監査(最新の攻撃パターンに基づいた擬似攻撃)を受けた場合に、IDS32およびVDS33の状態あるいはOS/アプリケーションのバージョン等を確認するソフトウェアまたはハードウェアである。本変形例においては、サーバ3のセキュリティレベルを証明する情報がセキュリティ証明書109に含まれているとする。
【0067】
また、本変形例においては、セキュリティ証明書109の発行はサーバ3が行い、セキュリティ保証局2は、サーバ3が発行したセキュリティ証明書109に対して署名を施す。サーバ3によって発行されたサーバ3自身のセキュリティ証明書109は仮の状態であり、セキュリティ保証局2によって署名が施された時点で、クライアント4にとって有効な証明書となる。
【0068】
セキュリティ保証局2は自身の公開鍵と秘密鍵のペアを作成し、既存の認証局からPKCの発行を受けておく。また、クライアント4は事前にセキュリティ保証局2のPKC108を受信し、保持しておく(ステップS21)。サーバ3はIDS32/VDS33やOS/アプリケーションのバージョンおよびパターンファイルの更新を行う(ステップS22)。続いて、サーバ3は、上記のセキュリティ対策の更新に伴って、セキュリティ証明書への署名要求を示す情報をセキュリティ保証局2へ送信する(ステップS23)。
【0069】
この情報を受信したセキュリティ保証局2は、サーバ3におけるIDS32およびVDS33の起動状態やパターンファイルの状態等を確認するために、前述した動作と同様にして攻撃パケットを連続的に生成し、サーバ3へ送信する(ステップS24;外部監査)。サーバ3において、通信部31は攻撃パケットを受信し、IDS32へ出力する。IDS32は記憶部38から最新のパターンファイルを読み出し、そのパターンファイルに基づいてパケットを監視し、最新の攻撃パターンと一致するパケットを検知した場合には、その攻撃パターン名(シグネチャ名)、送信元IP、時刻情報等を記憶部38のログに記録する。
【0070】
セキュリティ保証局2からの攻撃パケットがサーバ3に到着した後、内部監査モジュール39は所定のタイミングで内部監査を行う。すなわち、内部監査モジュール39は、IDS32およびVDS33の起動状態やパターンファイルの状態を確認し、前述したACの発行に必要な情報104と同様の情報を取得する。また、内部監査モジュール39はOSやアプリケーションの状態について、不審なアプリケーションやPortの設定等を検査し、内部監査の結果を示す情報を生成する(ステップS25)。
【0071】
サーバ3は、内部監査モジュール39が取得した情報に基づいて仮のセキュリティ証明書109を生成し、セキュリティ保証局2へ送信する。また、サーバ3は、内部監査の結果を示す情報およびログの情報を内部/外部監査結果110としてセキュリティ保証局2へ送信する(ステップS26)。セキュリティ保証局2の通信部21は上記のセキュリティ証明書109および内部/外部監査結果110を受信し、サーバとの通信制御部23を介してサーバ認証部25へ出力する。
【0072】
サーバ認証部25は、サーバ3に最新のセキュリティ対策が施されて、適切に運用されているかどうか検証する。すなわち、サーバ認証部25は、擬似攻撃のパケットを生成する際に用いた最新のパターンファイルに基づいた攻撃パターンがログに記録されているかどうか検証すると共に、セキュリティ証明書109の形式が所定の形式に沿っているかどうか、必要な情報が格納されているかどうか等を検証する。検証の結果、最新の攻撃パターンに基づいて更新された攻撃パターンがログに記録されており、セキュリティ証明書109の形式等が所定の条件を満たしていた場合には、サーバ認証部25は、サーバ3のセキュリティレベルを確認することができたとし、セキュリティ保証局2の秘密鍵を用いて署名情報を生成し、セキュリティ証明書109に付加する。サーバ認証部25は、サーバとの通信制御部23および通信部21を介してサーバ3へこのセキュリティ証明書109を送信する。サーバ3は、セキュリティ保証局2によって送信されたセキュリティ証明書109を受信する(ステップS27)。
【0073】
なお、セキュリティ保証局2が外部監査を行わず、サーバ3からの署名要求に基づいてサーバ3へ内部監査を指示し、内部監査に基づいてサーバ3が生成したセキュリティ証明書109の形式的な検証を行い、セキュリティ証明書109に署名を施すのみとしてもよい。セキュリティ保証局2が外部監査を行い、外部監査の結果をサーバ3のセキュリティレベルの検証の材料とすることにより、サーバ3のセキュリティレベルをより確実に確認および保証することができる。
【0074】
クライアント4は、通信の開始時点において、サーバ3に対してセキュリティ証明書109の提示を要求する(ステップS28)。サーバ3において内部監査モジュール39は内部監査を行い(ステップS29)、IDS32およびVDS33やパターンファイル等の状態がセキュリティ証明書109に格納された情報と同じ状態であるかどうか確認し、同じ状態であった場合には、セキュリティ保証局2の署名が付加されたセキュリティ証明書109をクライアント4へ送信する(ステップS30)。クライアント4はセキュリティ証明書109を受信し、クライアント4の署名検証部41は、セキュリティ保証局2の公開鍵を用いて、セキュリティ証明書109に付加されている署名の検証を行う(ステップS31)。検証の結果、署名が有効であった場合には、クライアント4はサーバ3と通信を開始する。
【0075】
次に、本実施形態の他の変形例について説明する。図6は、本変形例に係る通信システムの構成を示すブロック図である。本変形例においても、認証局1の図示は省略されている。本変形例のセキュリティ保証局2は、セキュリティ証明書の有効性の管理を行う失効証明書管理部29を備えている。また、サーバ3において、通信モジュール40は、前述した通信部31や、クライアント通信制御部34、SCAとの通信制御部37等を含むサーバ3と外部装置との通信を制御するハードウェアまたはソフトウェアである。
【0076】
本変形例においては、本通信システムの実装を図る上で有効な以下の3点について詳述する。
(A)セキュリティ保証局2とサーバ3との間、サーバ3とクライアント4との間、およびセキュリティ保証局2とクライアント4との間において、TCP/UDP上で動く新たな通信プロトコル。
(B)セキュリティ証明書の発行処理および失効処理。特に、失効処理については、従来のCRLを用いる処理方式に代わって、同一の内容を保証する複数のセキュリティ証明書を一斉に失効させる処理方式を示す。
(C)サーバ3の内部監査モジュール39の耐タンパ化を図る手法。
【0077】
まず、図6に示される本通信システムの概略動作を説明する。セキュリティ保証局2は自身の公開鍵と秘密鍵のペアを作成し、既存の認証局からPKCの発行を受けておく。また、クライアント4は事前にセキュリティ保証局2のPKC111を受信し、保持しておく(ステップS41)。サーバ3はIDS32/VDS33やOS/アプリケーションのバージョンおよびパターンファイルの更新を行う(ステップS42)。続いて、サーバ3は、上記のセキュリティ対策の更新に伴って、セキュリティ対策システムの更新状態を示すと共に、セキュリティ証明書への署名要求を示す情報をセキュリティ保証局2へ送信する(ステップS43)。
【0078】
続いて、内部監査モジュール39はOSやアプリケーションの状態について、不審なアプリケーションやPortの設定等を検査し、内部監査の結果を示す情報を生成する(ステップS44)。通信モジュール40は、内部監査の結果を示す情報を内部監査結果112としてセキュリティ保証局2へ送信する。セキュリティ保証局2は内部監査結果112を受信する(ステップS45)。セキュリティ保証局2は、サーバ3におけるIDS32およびVDS33の起動状態やパターンファイルの状態等を確認するために、前述した動作と同様にして攻撃パケットを連続的に生成し、サーバ3へ送信する(ステップS46;外部監査)。
【0079】
サーバ3において、IDS32は、前述した動作と同様にして、最新の攻撃パターンと一致するパケットに係る情報を記憶部38のログに記録する。通信モジュール40はログの情報を外部監査結果113としてセキュリティ保証局2へ送信する。セキュリティ保証局2は外部監査結果113を受信する(ステップS47)。内部監査と外部監査はどちらから先に行ってもよいが、本変形例においては内部監査が先に行われるものとする。
【0080】
セキュリティ保証局2は、前述した動作と同様にして、内部監査結果112および外部監査結果113に基づいて、サーバ3に最新のセキュリティ対策が施されて、適切に運用されているかどうか検証する。すなわち、サーバ認証部25は、擬似攻撃のパケットを生成する際に用いた最新のパターンファイルに基づいた攻撃パターンがログに記録されているかどうか検証すると共に、内部監査結果112に必要な情報が含まれているか、内部監査結果112によって示されるサーバ3のセキュリティ対策が最新のものであるかどうか等を検証する。
【0081】
検証の結果、最新の攻撃パターンに基づいて更新された攻撃パターンがログに記録されており、内部監査結果112が所定の条件を満たしていた場合には、サーバ3のセキュリティレベルを確認することができたとし、サーバ認証部25は、セキュリティ保証局2の秘密鍵を用いて署名情報を生成し、その署名情報を付加したセキュリティ証明書114を生成する。サーバ認証部25は、サーバとの通信制御部23および通信部21を介してサーバ3へセキュリティ証明書114を送信する。サーバ3はセキュリティ証明書114を受信する(ステップS48)。
【0082】
クライアント4は、通信の開始時点において、サーバ3に対してセキュリティ証明書114の提示を要求する(ステップS49)。サーバ3の通信モジュール40は、セキュリティ保証局2の署名が付加されたセキュリティ証明書114をクライアント4へ送信する(ステップS50)。本変形例においては、高速化のため、サーバ3の内部監査は省略されるものとする。サーバ3は、クライアント4からのセキュリティ証明書の提示要求に備えて、定期的に内部監査を行ってもよい。クライアント4はセキュリティ証明書114を受信し、署名検証部41は、セキュリティ保証局2の公開鍵を用いて、セキュリティ証明書114に付加されている署名の検証を行う(ステップS51)。
【0083】
検証の結果、署名が有効であった場合に、クライアント4はサーバ3へセキュリティ証明書114全体を送信するか、セキュリティ証明書114に付与されている証明書ID(後述するシリアル番号)を送信する(ステップS52)。セキュリティ保証局2の通信部21はセキュリティ証明書114または証明書IDを受信し、クライアントとの通信制御部24を介して失効証明書管理部29へ出力する。詳細は後述するが、失効証明書管理部29はセキュリティ証明書114が有効であるか失効であるかを検証し、検証結果を示す情報をクライアントとの通信制御部24へ出力する。クライアントとの通信制御部24は、通信部21を介して検証結果の情報をクライアント4へ送信する(ステップS53)。
【0084】
クライアント4は検証結果の情報を受信し、その情報に基づいて、セキュリティ証明書114の有効性を判断する。セキュリティ証明書114が失効しておらず、有効なセキュリティ証明書であると判断できた場合に、クライアント4はサーバ3との通信を開始する。
【0085】
次に、セキュリティ保証局2とサーバ3との間、サーバ3とクライアント4との間、およびセキュリティ保証局2とクライアント4との間の通信に用いられる通信プロトコルについて説明する。従来のPKIにおいては、公開鍵証明書への署名を受けたいサーバは、公の認証局に対して身元情報や公開鍵情報を、郵送等の物理的な経路を使って送っている。場合によっては、これらの情報がネットワーク経由で送られることもあるが、認証局側では何らかの物的証明を参照して、送られてきた情報の正当性の担保を取っている。
【0086】
しかしながら、セキュリティ証明書の場合、未知の攻撃やウィルスが発見されるたびに証明書の廃棄と更新を図る必要があり、即時性を保つためにも、全てネットワーク経由でオンライン化された処理が行われなければならない。ネットワーク経由で相手を確実に認証し、情報を盗聴されないようにするためにも、通信方式の検討は重要である。
【0087】
まず、セキュリティ保証局2とサーバ3との間の通信プロトコルを説明する。セキュリティ保証局2とサーバ3との間の通信は、既存の相互認証および暗号化プロトコルで安全な通信路を確保するフェーズから開始する。続いて、開始要求フェーズ、安全性評価フェーズ等が実施され、最後にセキュリティ証明書の発行が行われて終了する。
【0088】
図7は、セキュリティ保証局2およびサーバ3間の相互認証・暗号化の通信シーケンスを示している。相互認証と暗号化は、既存のSSL(Secure Socket Layer)やIPsec等のプロトコルを利用すればよく、証明書発行フェーズと独立しており、各種の相互認証・暗号化プロトコルを適用することができる。図7(a)は、SSLを用いた相互認証・暗号化の通信シーケンス例である。TCPの3Wayハンドシェーク(ステップS701a)に続いて、セキュリティ保証局2およびサーバ3はSSLの相互認証・暗号化を行い(ステップS702a)、後述する証明書発行処理を行う(ステップS703a)。SSLの終了処理(ステップS704a)およびTCPの終了処理(ステップS705a)が行われ、相互認証・暗号化が終了する。
【0089】
図7(b)は、IPsecを用いた相互認証・暗号化の通信シーケンス例である。IPsecの相互認証・暗号化(ステップS701b)に続いて、セキュリティ保証局2およびサーバ3はTCPの3Wayハンドシェークを行い(ステップS702b)、後述する証明書発行処理を行う(ステップS703b)。TCPの終了処理(ステップS704b)およびIPsecの終了処理(ステップS705b)が行われ、相互認証・暗号化が終了する。
【0090】
図8は、証明書発行フェーズの通信シーケンス例を示している。図8(a)は、証明書発行アプリケーション層で通信処理の確実性を持たせた方式であり、図8(b)は、確実性を下位通信レイヤに委ねて高速性を持たせた方式である。高速性を持たせた方式は、確実性を持たせた方式の処理から確認処理を省いたものとなっている。以下、確実性を持たせた方式を基準にして説明する。
【0091】
証明書発行のための通信においては、様々な形式およびサイズの情報を交換する必要があるため、自由フォーマットのテキストを通信するのに適したタグ囲み(<と>、および</と>の間に、情報の種別を表すテキストが挿入されたタグ同士の間に、情報の内容を表すテキストが挿入される文書構造)を用いることにする。すなわち、通信相手に通知される情報に対してタグが付加された形式のデータが送受信される。タグによって情報の種別が判断(識別)され、タグによって囲まれたテキストを参照することによって、情報の内容が判断(識別)される。
【0092】
相互認証・暗号化(ステップS801a、ステップS801b)開始フェーズにおいては、サーバ3はセキュリティ保証局2に対して、セキュリティ証明書の発行のための通信フェーズの開始を通知する。サーバ3は、開始パケットをセキュリティ保証局2へ送信し、セキュリティ証明書の発行要求を通知する(ステップS802a)。セキュリティ保証局2は、そのレスポンスとして確認パケットをサーバ3へ返信する(ステップS803a)。図9は開始パケットおよび確認パケットの内容を示している。「*」印はオプションである(以下同様)。
【0093】
続いて、更新・状態通知フェーズにおいて、サーバ3は、セキュリティ対策に関わる更新された情報を、更新・状態通知パケットによってセキュリティ保証局2に通知する(ステップS804a、ステップS802b)。この更新・状態通知パケットに含まれる情報は、セキュリティ対策システムの状態を示す状態情報(通知情報)であり、内部監査モジュール39が収集する。セキュリティ保証局2は、更新・状態通知パケットを受信し、確認パケットをサーバ3へ返信する(ステップS805a)。図10は、更新・状態パケットおよび確認パケットの内容を示している。
【0094】
図10において、「name」 印はOSやIDSの名前を、「version」 印はそれらのバージョン情報を、「pattern」印はパッチやパターンファイル情報を通知するための識別子である。「UP」 印は、更新された情報を表し、この印のない数値やテキスト情報のみが記載されているものは、更新のない現状を表している。VDS等のタグが例示されていないが(例:<status-vds>)、この場合には、VDSを持っていないか、もしくはVDSに関しては、保証の必要がないことを表している。
【0095】
多数のサーバのセキュリティ状態を保証するセキュリティ保証局2が各サーバの状態履歴管理をしなくてもよいように、各サーバは、セキュリティ保証局2に通知する情報に現状と更新の両状態の情報を含めることにする。これにより、セキュリティ保証局2はセキュリティ証明書の発行要求単位で発行の可否を判断することができる。もし、セキュリティ保証局2が各サーバの状態の履歴管理機能を有する場合には、各サーバが更新情報のみを通知することによって、セキュリティ保証局2は証明書の発行可否を判断することができる。署名を受ける各サーバの公開鍵情報(<pub-key>***</pub-key>参照)も通知される。
【0096】
続いて、内部監査指示フェーズにおいて、セキュリティ保証局2は、サーバ3に対して、内部監査すべき項目を要求し(ステップS806a、ステップS803b)、サーバ3はその要求に従った監査結果を報告する(ステップS807a、ステップS804b)。報告を受けたセキュリティ保証局2は確認パケットをサーバ3へ送信する(ステップS808a)。図11は内部監査指示パケット、内部監査結果パケット、および確認パケットの内容を示している。
【0097】
内部監査の結果は、サーバ3のセキュリティ対策システムの状態を示す状態情報であり、更新・状態通知フェーズにおいて、サーバ3がセキュリティ保証局2に通知した状態情報(通知情報)よりも詳細なセキュリティ対策システムの状態を示している。内部監査指示パケットによって、サーバ3が管理しているファイル(例:syslog)や、起動中のプロセス(例:psコマンド)をチェックすることが指示される。これに従い、サーバ3は、要求された情報をテキスト情報として含む内部監査結果パケットをセキュリティ保証局2へ返信する。返信サイズが大きくなる場合には、複数のパケットに分割される場合もある。場合によっては、サーバ3は特徴のみをハッシュ値として通知することもある。また、セキュリティ保証局2が、返信すべき箇所を指定することもあり、例えばキーワードや時刻情報をサーバ3に通知することで、返信すべき箇所を絞り込む。
【0098】
続いて、外部監査フェーズにおいて、セキュリティ保証局2からサーバ3に対する、攻撃パケット等による外部監査が行われる(ステップS809a、ステップS805b)。外部監査フェーズに続く外部監査指示フェーズにおいて、セキュリティ保証局2は、サーバ3側に記録された外部監査の結果を収集するため、外部監査指示パケットをサーバ3へ送信する(ステップS810a、ステップS806b)。サーバ3は、外部監査の結果をテキスト情報として含む外部監査結果パケットをセキュリティ保証局2へ送信する(ステップS811a、ステップS807b)。外部監査結果パケットを受信したセキュリティ保証局2は確認パケットをサーバ3へ送信する(ステップS812a)。
【0099】
図12は、外部監査指示パケット、外部監査結果パケット、および確認パケットの内容を示している。IDS等に記録されたログ情報を収集するために、外部監査指示パケットによって、収集すべき情報が指定される。外部監査は、セキュリティ保証局2から実施するとは限らない。また監査を実施するタイミングもまちまちである。さらに、結果ログ等の情報は膨大なサイズになる。これらのことより、収集すべき外部監査結果の箇所を特定する必要があり、セキュリティ保証局2は、外部監査指示パケットによって、外部監査を行ったIPアドレスや時刻、キーワード等を指定する情報を通知する。サーバ3は、指定された情報を、テキスト情報である外部監査結果パケットとして返信する。場合によっては、特徴のみをハッシュ値として通知することもある。
【0100】
続いて、セキュリティ証明書フェーズにおいて、セキュリティ保証局2は、内部監査と外部監査の結果、セキュリティ対策がサーバ3に正しく設定されている場合には、サーバ3に対して、セキュリティ証明書を発行して返信する(ステップS813a、ステップS808b)。サーバ3にセキュリティ対策が正しく設定されていない場合や、サーバ3から情報を正しく受け取れなかった場合には、セキュリティ保証局2はエラー情報(未対策通知パケット)を返信する。セキュリティ証明書を受け取ったサーバ3は確認パケットをセキュリティ保証局2へ送信する。図13はセキュリティ証明書パケットおよび未対策通知パケットの内容を示している。
【0101】
セキュリティ証明書には、発行者のIPアドレスと名前、バージョン番号、署名方式、署名の発行年月日、有効期限、サーバ名、サーバの公開鍵情報、セキュリティレベルが付与される。場合によっては、OSやIDS・VDSの状態が正しいということを示す情報も含まれる。また、後述するように、OSやIDS・VDSの状態に関する情報が、セキュリティ保証局2の公開鍵によって埋め込まれる場合もある。セキュリティ保証局2は、この情報を自身の秘密鍵で解くことによって、サーバ3の状態を示す情報を取り出し、セキュリティ証明書単位での有効性の確認を行う。
【0102】
セキュリティ証明書の末尾には署名情報が付与される。署名情報として、OSやIDSの状態を表す署名と、セキュリティ証明書全体の正当性を表す署名とがある。OSやIDSの状態をテキスト文のまま記載してしまうと、悪意の侵入者にセキュリティ対策情報(どのようなセキュリティ対策が施されているのかを表すセキュリティ対策の種別等を示す情報)を公開してしまうことが予想されるため、セキュリティ保証局2は、セキュリティ対策情報を抽象化した安全指数(<level>***</level>参照)をセキュリティ証明書に付加する。セキュリティ保証局2はセキュリティ対策情報と安全指数との対応表を管理しており、サーバ3から通知されたセキュリティ対策情報に基づいて、サーバ3の安全指数を決定する。もし、内部監査や外部監査の結果、サーバ3のセキュリティ対策が十分でないと判断した場合には、セキュリティ保証局2は、未対策通知パケットによって問題箇所をサーバ3に通知する。続いて、相互認証・暗号化終了フェーズを経て、通信が終了する(ステップS815a、ステップS809b)。
【0103】
本変形例においては、セキュリティ保証局2がセキュリティ証明書を発行しているが、前述した変形例と同様に、サーバ3が仮のセキュリティ証明書をセキュリティ保証局2へ送信し、セキュリティ証明書に対して、セキュリティ保証局2が署名を施すようにしてもよい。この場合の通信においても、本変形例と同様に、タグ囲みを用いた通信が行われる。
【0104】
次に、サーバ3およびクライアント4間の通信プロトコルを説明する。図14はサーバ3およびクライアント4間の通信シーケンスを示している。図14においては、証明書要求アプリケーションがTCPレイヤの上で動いている様子が示されている。図14(a)は、通信処理の確実性を持たせた方式であり、図14(b)は、確認処理を省いて高速性を持たせた方式である。
【0105】
TCPの3Wayハンドシェーク(ステップS1401a、ステップS1401b)に続いて、相互認証および暗号化が行われ(図示せず)、確実性を持たせた方式では開始パケットおよび確認パケットの送受信が行われる(ステップS1402a、ステップS1403a)。続いて、クライアント4は、サーバ3に対して、証明書要求パケットを送信する(ステップS1404a、ステップS1402b)。サーバ3は証明書要求パケットを受信し、証明書要求パケットによる要求に基づいて、セキュリティ証明書パケットをクライアント4へ送信する(ステップS1405a、ステップS1403b)。
【0106】
図15は、証明書要求パケットおよびセキュリティ証明書パケットの内容を示している。セキュリティ証明書パケットには、発行者名、バージョン、署名方式、発効日時、有効期限、サーバ名、セキュリティレベル等の情報がテキストとして含まれている。場合によっては、OSやIDSの状態が正しいことを通知するための情報も含まれる(<os-status>***</os-status>および<ids-status>***</ids-status>参照)。最後にセキュリティ保証局2の署名情報が付与される(<hash>***</hash>参照)。
【0107】
確実性を持たせた方式では、セキュリティ証明書パケットを受信したクライアント4は、確認パケットをサーバ3へ送信する(ステップS1406a)。続いて、TCPの終了処理が行われて、処理が終了する(ステップS1407a、ステップS1404b)。
【0108】
次に、セキュリティ保証局2およびクライアント4間の通信プロトコルを説明する。クライアント4側でのセキュリティ証明書の検証は、処理負荷の軽減と、セキュリティに関する確実性との観点から次の2つのレベルがある。
Level1)既に取得しているセキュリティ保証局2の公開鍵を用いたローカル検証
Level2)セキュリティ証明書の失効状態を確認するためにセキュリティ保証局2に問い合わせるオンライン検証
【0109】
Level1を実現するには、既存のPKIモデルと同様に、クライアント4が予めセキュリティ保証局2の公開鍵証明書を取得しておくことによって、セキュリティ証明書に付随する署名の有効性を検証することができる。クライアント4は外部との通信を必要とせず、処理負荷は軽い。
【0110】
しかしながら、未知の攻撃やウィルスが新たに出回り始めた場合に、セキュリティ証明書の有効性を確認する必要が生じる。有効期限内のセキュリティ証明書についても、クライアント4からセキュリティ保証局2に対して、失効状態の確認を頻繁に図ることが想定される。このとき、確実性を重視したLevel2のオンライン検証が必要になる。以下、Level2の方式を実現する手法を説明する。図16はクライアント4およびセキュリティ保証局2間のLevel2の通信シーケンスを示している。図16(a)は、通信処理の確実性を持たせた方式であり、図16(b)は、確認処理を省いて高速性を持たせた方式である。
【0111】
TCPの3Wayハンドシェーク(ステップS1601a、ステップS1601b)に続いて、相互認証および暗号化が行われ(図示せず)、確実性を持たせた方式では開始パケットおよび確認パケットの送受信が行われる(ステップS1602a、ステップS1603a)。続いて、クライアント4は、サーバ3から受信したセキュリティ証明書をセキュリティ保証局2へ送信し、セキュリティ証明書の有効性の確認を要求する(ステップS1604a、ステップS1602b)。
【0112】
セキュリティ保証局2はセキュリティ証明書を受信し、自身の公開鍵でセキュリティ証明書に署名したOSやIDSの状態情報を、秘密鍵を用いて取り出し、その有効性を確認し、有効性の確認結果をクライアント4に返信する(ステップS1605a、ステップS1603b)。このとき、クライアント4には、セキュリティ保証局2からの情報であることを保証するために、返信パケットの全体に対してセキュリティ保証局2の秘密鍵で署名した情報が送信される。図17はセキュリティ証明書パケットの内容、および有効性の確認結果である結果パケットの内容を示している。確実性を持たせた方式では、確認結果を示すパケットを受信したクライアント4は確認パケットをセキュリティ保証局2へ送信する(ステップS1606a)。続いて、TCPの終了処理(ステップS1607a、ステップS1604b)が行われ、処理が終了する。
【0113】
次に、セキュリティ保証局2によるセキュリティ証明書の発行および失効の手法を説明する。従来のPKIでは、各サーバに発行された証明書は、シリアル番号(前述した証明書ID)で管理されている。各証明書の有効期限は数年単位で設定されており、ひとたび発行された証明書の殆どが、有効期限内に失効することはない。よって、発行(更新)と失効の頻度は低く、個々の履歴をシリアル番号で管理することは可能である。このシリアル番号をCRL(Certificate Revocation List)に登録することによって、証明書の管理が実現されている。
【0114】
しかしながら、本実施形態におけるセキュリティ証明書の場合、新たな攻撃やウィルスが発見されるたびに、OSやIDS・VDSの設定ファイルが更新されることになり、発行(更新)と失効の頻度が高く、セキュリティ保証局2は膨大な数のセキュリティ証明書の状態を管理することになる。以下では、従来のCRLによる管理手法の適用も検討するが、セキュリティ保証局2側で、発行したセキュリティ証明書の履歴管理を行う必要のない管理手法についても検討が必要である。
【0115】
以下では、セキュリティ証明書の中に、セキュリティ保証局2のみが読み出せるサーバ3のセキュリティ対策情報を持たせることによって、セキュリティ保証局2はセキュリティ証明書を参照するだけで、その有効性(失効性)を判定することができる方式を説明する。これは、サーバ3のセキュリティ対策情報を、クライアント4に取得されないようにするために、セキュリティ証明書内に暗号化して保存する手法であり、悪意のクライアント対策を考慮した安全性を重視した方式である。
【0116】
また、頻繁にセキュリティ証明書の有効性を確認しなければならない本実施形態の場合、クライアント4がセキュリティ保証局2に問い合わせる頻度が高くなり、セキュリティ保証局2側で輻輳する可能性もある。したがって、発行した個々のセキュリティ証明書を管理するのではなく、グループ単位で有効性を判定する手法についても検討する必要がある。
【0117】
以下では、失効処理の負荷の軽減を目的として、同一種類のOSやIDS・VDSが適用されているサーバに対して、同一種類のセキュリティ証明書を発行することで、セキュリティ証明書の種別ごとに一斉に失効させる手法を説明する。これによって、セキュリティ証明書の失効判定処理の簡易化を図ることができる。
【0118】
まず、CRLによるセキュリティ証明書の管理手法を本実施形態に適用した場合を説明する。セキュリティ保証局2は、発行した個々のセキュリティ証明書に、固有のシリアル番号を付与する。セキュリティ証明書を失効させる際には、セキュリティ保証局2は、この番号をCRLに登録する。この手法は、失効管理を実現する従来のPKIモデルと同じ方式である。この場合、OSやIDS・VDSに関する情報をセキュリティ証明書に付与する必要はない。セキュリティ証明書の有効性を判断する場合、セキュリティ保証局2の失効証明書管理部29は、セキュリティ証明書に付与されているシリアル番号とCRL中のシリアル番号とを照合し、両者が一致した場合に、そのセキュリティ証明書が失効状態である(有効でない)と判断する。
【0119】
次に、セキュリティ証明書の中にサーバ3のセキュリティ対策情報(どのようなセキュリティ対策が施されているのかを表すセキュリティ対策種別等を示す情報)を、セキュリティ保証局2のみが読み出せるように格納する手法を説明する。セキュリティ保証局2から発行されたセキュリティ証明書にサーバ3のセキュリティ対策情報を、セキュリティ保証局のみが読み出せる手法で埋め込んでおくことによって、クライアント4からセキュリティ保証局2に対して、有効性に関する問い合わせがあった場合にも、セキュリティ保証局2は、セキュリティ証明書の情報を参照するだけで、その有効性を判定することができる。ここで注意すべきことは、セキュリティ証明書の中に、OSやIDS・VDSの名前やバージョン等の情報を直接(誰でも読み出せる形で)埋め込まないことである。
【0120】
セキュリティ保証局2のサーバ認証部25は、セキュリティ証明書を発行する際に、セキュリティ証明書に付与するセキュリティ対策情報として、サーバ3から通知されたOSやIDS・VDSの名前およびバージョン・パターンファイル情報と、パディングのための乱数とを1つの情報として扱い、この情報に対して、自身の公開鍵で暗号化を施す。セキュリティ保証局2は、暗号化して得た暗号データをセキュリティ証明書に付加する。暗号化の様子は、図13等における証明書タグ<secret-os> *** </secret-os> や <secret-ids>*** </secret-ids> で表されている。
【0121】
セキュリティ保証局2は各セキュリティ証明書の固有のシリアル番号を管理することはせず、セキュリティ対策の種別を示すOSやIDS・VDSのバージョンと、その有効性を示す情報とが関連付けられたテーブル(失効情報テーブル)を記憶部28に格納している。セキュリティ証明書の有効性を判断する際に、サーバ認証部25は、セキュリティ証明書に含まれる、暗号化されたセキュリティ対策情報をセキュリティ保証局2の秘密鍵で復号化する。サーバ認証部25は、記憶部28から失効情報テーブルを読み出し、復号化によって得たセキュリティ対策情報の内容と照合することによって、セキュリティ証明書の有効性を判断する。すなわち、セキュリティ証明書に含まれていたセキュリティ対策情報によって示されるOS等のバージョンが、失効情報テーブル上で失効となっていた場合、サーバ認証部25は、セキュリティ証明書が失効していると判断する。
【0122】
この手法によれば、セキュリティ保証局2は、膨大な数の個々のセキュリティ証明書のシリアル番号を管理する必要がなくなるので、セキュリティ保証局2において必要な記録容量を削減し、セキュリティ保証局2の管理コストを低減することができる。また、サーバ3のセキュリティ対策情報が暗号化されてセキュリティ証明書に付加されているので、サーバ3のセキュリティ対策情報が漏洩する危険性を低減することができる。
【0123】
次に、種別ごとにセキュリティ証明書を一斉に失効させる手法を説明する。サーバ認証部25は、同一種類のOSやIDS・VDSが適用されている複数のサーバに対して、同一種類の識別情報を有するセキュリティ証明書を発行する。サーバ認証部25は、セキュリティ対策種別を識別するシリアル番号をセキュリティ証明書に付与する。セキュリティ対策種別は、OSやIDS・VDSのバージョンによって示される。
【0124】
記憶部28には、セキュリティ対策種別およびそのシリアル番号と、有効性を示す情報とが関連付けられた失効情報テーブルが格納されている。サーバ認証部25は、クライアント4から受信されたサーバ3のセキュリティ証明書に含まれるシリアル番号と、記憶部28から読み出した失効情報テーブル中のシリアル番号とを照合する。両者が一致した場合、サーバ認証部25は、失効情報テーブルの内容に基づいて、そのバージョンの有効性を判断する。そのバージョンが失効状態である場合、サーバ認証部25はセキュリティ証明書が失効状態である(有効でない)と判断する。
【0125】
セキュリティ証明書が失効するタイミングは、セキュリティ証明書の有効期限内にOSのバージョンが更新される場合や、IDS・VDSの検知パターンファイルが公開される場合である。上記のように、同一種類のセキュリティ対策種別を有する複数のサーバに対して、セキュリティ対策種別に関して同一内容のセキュリティ証明書が発行されるため、OS、IDS、およびVDSの個々のセキュリティ対策種別ごとにセキュリティ証明書が一斉に失効することになる。
【0126】
失効は、セキュリティ対策種別ごとに生成されたセキュリティ証明書内のシリアル番号で管理される。この手法でセキュリティ保証局2から公開される失効情報は、有効期限内に失効することになったセキュリティ証明書のシリアル番号のみとする。図13等に示されるセキュリティ証明書中の<secret-os>***</secret-os> や <secret-ids>***</secret-ids> で表されている情報の箇所へ、セキュリティ対策種別ごとのシリアル番号が付与される。この場合、セキュリティ証明書全体へのシリアル番号は不要になる。
【0127】
以下、セキュリティ対策種別ごとに付与するシリアル番号から、セキュリティ対策情報を推測し難くする手法について、OS種別とバージョンを例にして説明する。OSには複数種類あり、そのバージョンにも様々なものがある。図18は、シリアル番号および失効状態のOSならびにバージョン情報を管理する失効情報テーブルの様子を示している。このテーブルは、セキュリティ保証局2の失効証明書管理部29によって作成されて、管理される。また、このテーブルは記憶部28に格納されている。
【0128】
シリアル番号は、A、B、C・・・で表されるグループIDと昇順数値とによって構成されている。失効状態に関しては、あるグループのある数値が失効した場合、同じグループ内のその数値以下の全ての数値が失効となる。例えばグループDの004まで失効した場合、Dグループのそれ以下(000〜003)の数値が関連付けられたセキュリティ証明書は全て失効される。図18(a)においては、グループBの000〜002およびグループDの000〜001に関連付けられたセキュリティ証明書は全て失効している。失効情報テーブルには、グループBの002およびグループDの001が失効しているという情報が含まれている。その数値以下の数値は全て失効しているから、全ての昇順数値に対して失効しているか否かの情報(フラグ等)を用意する必要はない。これによって、セキュリティ保証局2において必要な記録容量を削減し、セキュリティ保証局2の管理コストを低減することができる。
【0129】
セキュリティ対策情報を推定され難くするために、同じOSとバージョンであっても、複数のグループIDと複数の数値で管理されることにする。図18には、OSxxxとOSyyyが複数のグループで管理されている様子や、OSxxx−v1.1とOSzzz−v1.2が複数の数値で管理されている様子が示されている。同じOSとバージョンを持つサーバがあったとしても、セキュリティ証明書によってはグループIDや昇順数値が異なる場合もあり、互いに同じ設定であることを認識できないようになる。推定の困難性は、グループIDの数や昇順数値の数に依存する。
【0130】
OSyyyのバージョン1.3までが失効状態であった場合(図18(a))、Dグループの000〜001が失効となっている。Dグループの002以後には別のOSxxxの管理が割り当てられている。さらに時間が進み、OSxxxのバージョン1.2まで失効されていることを想定する(図18(b))。このとき、Aグループの003まで全て失効された状態となり、A−004以後には別のOSyyyを割り当てることができる。
【0131】
図18(a)の状態では、A−003は失効しておらず、この状態でA−004以後に別のOSyyyを割り当ててしまうと、OSxxx−v1.2よりもOSyyyの方が先に失効してしまう可能性がある。したがって、図18(b)の状態となってから、A−004以後に別のOSyyyが割り当てられるようになる。失効証明書管理部29は、シリアル番号の昇順数値を付与する際に、上記のように、ある昇順数値が付与されたバージョンが失効であった場合に、同一グループのその数値以下の昇順数値が付与されたバージョンが全て失効状態となっているという関係を満たすように、昇順数値を付与する。
【0132】
悪意のサーバが様々なOSやバージョン情報をセキュリティ保証局2に申請して、多数の証明書を集めることによって、シリアル番号の対応表を推定することができる可能性がある。この攻撃に対しては、セキュリティ保証局2が、セキュリティ証明書の発行頻度を制限することによって、防ぐことができる。
【0133】
セキュリティ保証局2はシリアル番号と、その番号を最後に発行した日時情報とを管理しておく。この日時情報を基に、有効期限の切れたセキュリティ証明書のシリアル番号は公開しないことにして、失効情報の量を軽減させる。図18(b)では、B−002が、有効期限切れのセキュリティ証明書に付与されたシリアル番号であり、A−003とD−002の2つが、失効情報としてセキュリティ保証局2から公開される。
【0134】
上述した手法によれば、セキュリティ対策種別に関して同一内容のセキュリティ証明書の有効性をグループ単位の数値で判断することができ、セキュリティ保証局2の負荷を軽減することができる。また、失効したOS等のバージョンのグループIDと昇順数値を公開しておくことによって、クライアント側でも容易にセキュリティ証明書の失効判定を行うことができる。
【0135】
また、同一のOSやIDS・VDS等のバージョンに対して、グループIDおよび昇順数値の組を複数割り当てることによって、サーバのセキュリティ対策情報を推測し難くすることができる。さらに、前述した、サーバ3のセキュリティ対策情報をセキュリティ保証局2が暗号化してセキュリティ証明書に埋め込む手法と比較して、セキュリティ証明書のサイズを小さくすることができる。
【0136】
なお、本変形例において説明したセキュリティ証明書の発行および失効の手法を、前述した変形例に適用してもよい。
【0137】
次に、サーバ3の内部監査モジュール39の耐タンパ化を図る手法を説明する。セキュリティ証明書の内容を保証するために、内部監査モジュール39の役割は重要である。もし内部監査モジュール39に関わる処理が攻撃され、IDS32やVDS33が停止しているにも関わらず、サーバ3がセキュリティ証明書をクライアント4に返信していたら、本実施形態によるPKI基盤モデルの信用が失われてしまうことになる。
【0138】
攻撃例として、i)内部監査モジュール39が起動しているサーバ3のOS自体が攻撃されて乗っ取られることで、OSが内部監査モジュール39に偽の情報を返信する攻撃がある。また、ii)内部監査モジュール39自体が攻撃されて、なりすまされることで、セキュリティ保証局2と偽の情報を交換する攻撃や、クライアント4に偽のセキュリティ証明書を返信してしまう攻撃が考えられる。そこで本変形例では、最も重要な役割を果たす内部監査モジュール39の耐タンパ化を、TCG(Trusted Computing Group)で検討されているTPM(Trusted Platform Module)の技術を用いて実現する手法と、スマートカード(ICカード)を用いて実現する手法とを提案する。
【0139】
まず、TCGについて説明する。TCGとは、ハードウェアからBIOS、OSに至るまで、アプリケーションを実行する環境を、信頼できるプラットフォームとして実現することを目指す業界標準化団体である。具体例として、コンピュータ上にハードウェアチップを組み込み、ソフトウェアから不正に操作することができない秘密情報(暗号鍵等)をそのハードウェアチップに格納するといったことが挙げられる。このチップのことをTPMという。いわゆる、コンピュータに内蔵されたセキュリティチップのことである。
【0140】
TPMを構成する機能として必要なものを以下に示す。
(1)プラットフォーム完全性の計測:BIOS、OS、ソフトウェアの改竄を発見するための、ソフトウェアのハッシュ値を保存する機能。
(2)プラットフォームの認証:正当なTPMが使用されていることを保障するための、TPM内に格納する秘密鍵の生成、保持機能。
(3)保護メモリ領域:秘密鍵を安全に保管するための、保護された記憶機能。
(4)暗号処理用コプロセッサ:暗号処理を安全に行うための公開鍵暗号演算、乱数発生、ハッシュ演算機能。
【0141】
TPMが上述した機能を備えることによって、図19に示されるように、TPMの実装位置を信頼点として、OS、Boot Loader、BIOS等の完全性の確認が可能となり、信頼性が保たれる(信頼の連鎖)。例えば、TPMにはOS等のハッシュ値が格納されており、OS等が改竄された場合には、そのハッシュ値が変化するので、改竄できないTPM中のハッシュ値と比較することによって、OS等の改竄の有無を検出することができる。
【0142】
一方、スマートカード(ICチップとも呼ばれる)とは、CPUやメモリ、セキュリティ回路等のICチップを組み込んだクレジットカード大のプラスチックカードである。スマートカードは、外部からの物理的な攻撃を受けた場合、チップ自体が破損する。また、守るべきプログラムはROMに焼き付けられており、外部のソフトウェア等でそのプログラムを書き換えることは不可能である。また、スマートカードは、重要な情報に暗号化を施して記憶することができる等の特徴を持っている。セキュリティ保証基盤で利用するスマートカードは、サーバ3のインタフェースに差し込む形態とし、暗号化等の演算能力、秘密情報の記憶領域、通信機能をスマートカードに持たせる。
【0143】
サーバ3内部にセキュリティチップを持たせて、そこで守るべき秘密情報と、この秘密情報を基に間接的に守られる情報を以下で列挙する。ちなみに、セキュリティチップを信頼点として、信頼の連鎖により間接的に守られる情報は、通常の記憶領域(ハードディスク等)で管理される。
【0144】
TPMやスマートカードの記憶領域、計算処理能力、通信能力が高い場合、守るべき情報と信頼の連鎖で守られる情報は図20(a)の通りとなる。セキュリティチップの能力が高い場合には、BIOS、Boot Loader、OSの他、内部監査モジュール39や通信インタフェース(通信モジュール40)の機能を実現する処理回路自体をセキュリティチップ内に実装することができる。また、TPMやスマートカードの記憶領域、計算処理能力、通信能力が低い場合、守るべき情報と信頼の連鎖で守られる情報は図20(b)の通りとなる。セキュリティチップの能力が低い場合には、内部監査モジュール39等の機能を実現する処理回路自体はセキュリティチップとは別のハードウェアによって構成し、セキュリティチップ内に内部監査モジュール39等のハッシュ値を格納しておく。
【0145】
次に、セキュリティGW(ゲートウェイ)に対して、耐タンパ化されたモジュールを実装した例を説明する。TPMやスマートカードを用いて信頼点を作成するには、サーバにセキュリティチップを実装するよりも、ブロードバンドルータやホームGWに実装してセキュリティGWとする方が容易に実現できる。図21は、セキュリティGWにセキュリティチップを実装した場合の通信システムの構成を示している。
【0146】
図において、セキュリティGW9に高性能なセキュリティチップ91が実装され、セキュリティGW9自身のOS、内部監査モジュール、通信モジュール、秘密鍵が、セキュリティチップ91によって管理されている。セキュリティ保証局2やクライアント4との通信処理は、セキュリティチップ91内に設けた通信モジュールを経由して行われる。内部監査モジュールは、セキュリティGW9自身のIDS・VDSの状態を監視する。また、セキュリティチップ91は、LANに接続されている各種機器(図21の各種端末12やサーバ13等)のOSやアプリケーション、場合によってはVDS等の状態を、外部監査によって監視する。
【0147】
なお、本変形例において説明した内部監査モジュール39の耐タンパ化の手法を、前述した変形例に適用してもよい。
【0148】
上述したように本実施形態においてサーバ3は、自身のセキュリティレベル(通信上の安全性)を示すIDS32またはVDS33に関しての、ACの発行に必要な情報104をセキュリティ保証局2へ送信する。セキュリティ保証局2は、ACの発行に必要な情報104に基づいてサーバ3のセキュリティレベル(通信上の安全性)を検証し、セキュリティレベルを確認することができた場合に、AC105を発行し、サーバ3へ送信する。また、サーバ3は、クライアント4からの接続要求があった場合に、クライアント4へAC105を送信し、クライアント4はAC105に基づいて、サーバ3のセキュリティレベルを検証する。
【0149】
上記により、クライアント4は、サーバ3のセキュリティレベルが、第三者機関であるセキュリティ保証局2によって証明されていることをサーバ3との通信前にAC105から知ることができる。したがって、セキュリティ保証局2、サーバ3、およびクライアント4に対して上記のような機能を持たせることによって、通信相手がセキュリティ対策を施していることを保証し、より安全なネットワーク基盤を構成することができるようになる。
【0150】
また、本実施形態の他の動作によれば、サーバ3は、本人性(識別性)を示すPKC102をセキュリティ保証局2へ送信し、セキュリティ保証局2は、PKC102に基づいてサーバ3の本人性を検証し、本人性およびセキュリティレベルを確認することができた場合に、AC105を発行し、サーバ3へ送信する。さらに、サーバ3は、クライアント4からの接続要求があった場合に、クライアント4へPKC102を送信し、クライアント4は、PKC102に基づいて、サーバ3の本人性を検証する。上記により、通信相手がセキュリティ対策を施していることをより確実に保証することができる。
【0151】
また、本実施形態の他の動作によれば、セキュリティ保証局2およびサーバ3は、公開鍵暗号認証方式またはパスワード認証方式による両方向の認証に続いて暗号通信を行い、セキュリティ保証局2はサーバ3を遠隔操作し、ACの発行に必要な情報104に相当する情報をサーバ3から取得する。あるいは両方向の認証に続いてサーバ3がACの発行に必要な情報を主体的にセキュリティ保証局2へ送信する。これにより、上記と同様の効果を得ることができると共に、悪意のサーバがIDSやVDSによる通信の監視を行っていないにもかかわらず、ACの発行依頼を行う事態を防止し、サーバ3のセキュリティレベルをより確実に確認および保証することができる。
【0152】
また、本実施形態の他の動作によれば、サーバ3は、難読化等により耐タンパ性を有するプログラムに従って、IDS32またはVDS33の状態を示す状態情報を生成してセキュリティ保証局2へ送信し、セキュリティ保証局2は状態情報を受信し、状態情報の内容が、ACの発行に必要な情報104に含まれる情報の内容と一致するかどうか検証する。これにより、サーバ3のセキュリティレベルをより確実に確認および保証することができる。
【0153】
また、本実施形態の他の動作によれば、セキュリティ保証局2は、最新のパターンファイルに基づいた攻撃をサーバ3に対して行い、サーバ3のIDS32またはVDS33は、セキュリティ保証局2からの受信等により予め保持する最新のパターンファイルに基づいて、セキュリティ保証局2による攻撃を検知し、ログに記録する。サーバ3はログをセキュリティ保証局2へ送信し、セキュリティ保証局2は、サーバ3に対して行った攻撃がログに記録されているかどうか検証することにより、サーバ3が最新のパターンファイルに基づいたセキュリティ対策を行っているかどうか確認する。これにより、サーバ3のセキュリティレベルをより確実に確認および保証することができる。
【0154】
また、本実施形態の変形例によれば、サーバ3がIDS32およびVDS33の状態等を確認して仮のセキュリティ証明書109を発行し、このセキュリティ証明書109に対してセキュリティ保証局2が署名を行うことにより、セキュリティ保証局2が実施していたセキュリティ証明書の発行処理がサーバ3側に移るため、セキュリティ保証局2が多数のサーバを管理する場合にはその処理負荷を軽減することができる。
【0155】
また、本実施形態の他の変形例によれば、セキュリティ保証局2とサーバ3との間で行われるセキュリティ証明書の発行のための通信において、通信相手に通知される情報に対して、その情報を識別するタグが付加される。これによって、データに含まれるタグの順番等に依存せずに、情報を判別することができるので、セキュリティ保証局2およびサーバ3が様々な形式やサイズの情報を効率よく交換することができる。
【0156】
また、本実施形態の他の変形例によれば、セキュリティ保証局2は、サーバ3のセキュリティ対策の種別を示すセキュリティ対策情報に対して、自身の公開鍵で暗号化を施して暗号データを生成し、その暗号データをセキュリティ証明書に付加する。セキュリティ保証局2は、クライアント4からセキュリティ証明書の有効性の確認を要求された場合に、セキュリティ証明書に付加された暗号データを自身の秘密鍵で復号化することによって得たセキュリティ対策情報に基づいて、セキュリティ証明書の有効性を判断する。これによって、セキュリティ保証局2は、膨大な数のセキュリティ証明書の個々のシリアル番号を管理する必要がなくなるので、セキュリティ保証局2において必要な記録容量を削減し、セキュリティ保証局2の管理コストを低減することができる。さらに、サーバ3のセキュリティ対策情報が暗号化されてセキュリティ証明書に付加されているので、サーバ3のセキュリティ対策情報が漏洩する危険性を低減することができる。
【0157】
また、本実施形態の他の変形例によれば、セキュリティ保証局2は、同一のセキュリティ対策種別を有する複数のサーバに対して、同一のシリアル番号を有するセキュリティ証明書を発行する。換言すると、セキュリティ保証局2は、セキュリティ対策種別ごとに異なるシリアル番号をセキュリティ証明書に付与する。セキュリティ保証局2は、シリアル番号とセキュリティ対策種別、ならびに有効性(失効状態であるかどうか)を示す情報が関連付けられた失効情報テーブルと、セキュリティ証明書に付加されたシリアル番号とに基づいて、セキュリティ証明書の失効状態を判断する。これによって、セキュリティ証明書の有効性の判断に係るセキュリティ保証局2の負荷を軽減することができる。
【0158】
また、本実施形態の他の変形例によれば、TPMやスマートカード等のセキュリティチップをサーバ3に実装し、セキュリティチップ自体に内部監査モジュール39の処理回路を設ける、あるいはセキュリティチップに内部監査モジュール39のハッシュ値を格納することによって、内部監査モジュール39の改竄を防止し、サーバ3のセキュリティレベルをより確実に確認および保証することができる。
【0159】
以上、図面を参照して本発明の実施形態について詳述してきたが、具体的な構成はこれらの実施の形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計変更等も含まれる。
【図面の簡単な説明】
【0160】
【図1】本発明の一実施形態による通信システムの構成を示すブロック図である。
【図2】同実施形態によるセキュリティ保証局の構成を示すブロック図である。
【図3】同実施形態によるサーバの構成を示すブロック図である。
【図4】同実施形態における属性証明書の内容を確認するための表示を示す参考図である。
【図5】同実施形態の変形例による通信システムの構成を示すブロック図である。
【図6】同実施形態の他の変形例による通信システムの構成を示すブロック図である。
【図7】同実施形態の他の変形例における通信シーケンスを示すシーケンス図である。
【図8】同実施形態の他の変形例における通信シーケンスを示すシーケンス図である。
【図9】同実施形態の他の変形例におけるパケットの内容を示す参考図である。
【図10】同実施形態の他の変形例におけるパケットの内容を示す参考図である。
【図11】同実施形態の他の変形例におけるパケットの内容を示す参考図である。
【図12】同実施形態の他の変形例におけるパケットの内容を示す参考図である。
【図13】同実施形態の他の変形例におけるパケットの内容を示す参考図である。
【図14】同実施形態の他の変形例における通信シーケンスを示すシーケンス図である。
【図15】同実施形態の他の変形例におけるパケットの内容を示す参考図である。
【図16】同実施形態の他の変形例における通信シーケンスを示すシーケンス図である。
【図17】同実施形態の他の変形例におけるパケットの内容を示す参考図である。
【図18】同実施形態の他の変形例における失効情報テーブルの内容を示す参考図である。
【図19】同実施形態の他の変形例における内部監査モジュールの耐タンパ化を説明するための参考図である。
【図20】同実施形態の他の変形例における守るべき情報と守られる情報を説明するための参考図である。
【図21】同実施形態の他の変形例における通信システムの構成を示すブロック図である。
【図22】従来の公開鍵証明書および属性証明書のデータ構造を示す参考図である。
【図23】従来の認証局および属性認証局による公開鍵証明書および属性証明書の発行・指定関係を示す参考図である。
【図24】従来の失効証明書リストのデータ構造を示す参考図である。
【図25】従来のIDSの構成を示すブロック図である。
【符号の説明】
【0161】
1・・・認証局、2・・・セキュリティ保証局、3,13・・・サーバ、4・・・クライアント、5・・・IDS・VDSベンダ、6・・・属性認証局、7・・・端末、8,32・・・IDS、9・・・セキュリティGW、10・・・インターネット、11a,11b・・・ネットワーク、12・・・各種端末、21,31・・・通信部、22・・・IDS・VDSベンダからの情報取得部、23・・・サーバとの通信制御部、24・・・クライアントとの通信制御部、25・・・サーバ認証部、26・・・サーバへのIDS・VDSパターンファイル適用部、27・・・属性証明書発行部、28,38・・・記憶部、29・・・失効証明書管理部、33・・・VDS、34・・・クライアント通信制御部、35・・・クライアントからのセッション受付部、36・・・IDS/VDSの起動監視部、37・・・SCAとの通信制御部、39・・・内部監査モジュール、40・・・通信モジュール、41・・・署名検証部、81・・・パケット取得部、82・・・攻撃検査部
【特許請求の範囲】
【請求項1】
通信元装置と、該通信元装置と通信を行う通信相手装置と、前記通信相手装置の通信上の安全性を保証する安全性保証装置とを具備する通信システムであって、
前記通信相手装置は、自身の通信上の安全性を通知するための通知情報を前記安全性保証装置へ送信し、
前記安全性保証装置は、前記通知情報を受信し、該通知情報に基づいて前記通信相手装置の通信上の安全性を検証し、該通信上の安全性を確認した場合に、該通信上の安全性を証明する安全性証明情報を生成して前記通信相手装置へ送信し、
前記通信相手装置は、前記安全性証明情報を受信し、前記通信元装置からの接続要求に応じて前記安全性証明情報を前記通信元装置へ送信し、
前記通信元装置は、前記通信相手装置に対する接続要求の後、前記通信相手装置から前記安全性証明情報を受信し、該安全性証明情報に基づいて前記通信相手装置の通信上の安全性を検証する
ことを特徴とする通信システム。
【請求項2】
前記通信相手装置および前記安全性保証装置は、両方向の認証を行い、
該認証に続いて前記安全性保証装置は、前記通信相手装置を制御および操作する操作情報を前記通信相手装置へ送信し、該操作情報に基づいて前記通知情報を生成した前記通信相手装置から前記通知情報を受信すると共に、該通知情報に基づいて前記通信相手装置の通信上の安全性を検証する
ことを特徴とする請求項1に記載の通信システム。
【請求項3】
前記通信相手装置および前記安全性保証装置は、両方向の認証を行い、
該認証に続いて前記通信相手装置は前記通知情報を生成して前記安全性保証装置へ送信し、
前記安全性保証装置は、前記通知情報を受信し、該通知情報に基づいて前記通信相手装置の通信上の安全性を検証する
ことを特徴とする請求項1に記載の通信システム。
【請求項4】
前記通信相手装置は、セキュリティ対策システムを備え、耐タンパ性を有するプログラムに従って、前記セキュリティ対策システムの状態を確認し、該状態に関する状態情報を生成して前記安全性保証装置へ送信し、
前記安全性保証装置は前記状態情報を受信し、前記通知情報および前記状態情報に基づいて前記通信相手装置の通信上の安全性を検証する
ことを特徴とする請求項1に記載の通信システム。
【請求項5】
前記通信相手装置は、セキュリティ対策システムを備え、
前記安全性保証装置は、最新の攻撃パターンを示すパターン情報に基づいた攻撃を前記通信相手装置に対して行い、
前記セキュリティ対策システムは、予め所持する前記パターン情報に基づいて、前記安全性保証装置による攻撃を検知し、
前記通信相手装置は、前記セキュリティ対策システムによって検知された攻撃を示す攻撃検知情報を前記安全性保証装置へ送信し、
前記安全性保証装置は、前記攻撃検知情報を受信し、前記通知情報に代えて、前記攻撃検知情報および前記パターン情報に基づいて、前記通信相手装置の通信上の安全性を検証する
ことを特徴とする請求項1に記載の通信システム。
【請求項6】
前記通信相手装置はセキュリティ対策システムを備え、前記通知情報は、前記セキュリティ対策システムにより通信を監視している事実を示す情報を含むことを特徴とする請求項1に記載の通信システム。
【請求項7】
前記通信相手装置はさらに、自身の識別性を証明する識別性証明情報を前記安全性保証装置へ送信し、
前記安全性保証装置はさらに、前記識別性情報を受信し、該識別性証明情報に基づいて前記通信相手装置の識別性を検証し、前記通信相手装置の識別性および前記通信上の安全性を確認した場合に、前記安全性証明情報を生成して前記通信相手装置へ送信する
ことを特徴とする請求項1に記載の通信システム。
【請求項8】
前記通信相手装置はさらに、前記通信元装置からの接続要求に応じて、自身の識別性を証明する識別性証明情報を前記通信元装置へ送信し、
前記通信元装置はさらに、前記通信相手装置に対する接続要求の後、前記通信相手装置から前記識別性証明情報を受信し、該識別性証明情報に基づいて、前記通信相手装置の識別性を検証する
ことを特徴とする請求項1に記載の通信システム。
【請求項9】
前記通信相手装置は、前記通知情報に対して、識別用のタグを付加して前記安全性保証装置へ送信し、
前記安全性保証装置は、前記通知情報を受信し、前記タグに基づいて前記通知情報を識別し、前記通知情報に基づいて前記通信相手装置の通信上の安全性を検証し、前記通信上の安全性を確認した場合に、前記安全性証明情報を前記通信相手装置へ送信する
ことを特徴とする請求項1に記載の通信システム。
【請求項10】
前記通信相手装置は、自身が有するセキュリティ対策システムの状態を確認し、前記状態を示す状態情報を前記安全性保証装置へ送信し、
前記安全性保証装置は、前記状態情報を受信し、前記状態情報に基づいて前記通信相手装置の通信上の安全性を検証し、前記通信上の安全性を確認した場合に、前記安全性証明情報を生成して前記通信相手装置へ送信し、
前記通信相手装置において、前記セキュリティ対策システムの状態を確認する手段は、耐タンパ性を有するセキュリティチップ内に設けられている
ことを特徴とする請求項1に記載の通信システム。
【請求項11】
前記通信相手装置は、自身が有するセキュリティ対策システムの状態を確認し、前記状態を示す状態情報を前記安全性保証装置へ送信し、
前記安全性保証装置は、前記状態情報を受信し、前記状態情報に基づいて前記通信相手装置の通信上の安全性を検証し、前記通信上の安全性を確認した場合に、前記安全性証明情報を生成して前記通信相手装置へ送信し、
前記通信相手装置において、前記セキュリティ対策システムの状態を確認する手段のハッシュ値が、耐タンパ性を有するセキュリティチップ内に格納されている
ことを特徴とする請求項1に記載の通信システム。
【請求項12】
通信元装置と、該通信元装置と通信を行う通信相手装置と、前記通信相手装置の通信上の安全性を保証する安全性保証装置とを具備する通信システムであって、
前記通信相手装置は、自身の通信上の安全性を証明する安全性証明情報を前記安全性保証装置へ送信し、
前記安全性保証装置は、前記安全性証明情報を受信し、該安全性証明情報に対して署名情報を付加して、前記安全性証明情報を前記通信相手装置へ送信し、
前記通信相手装置は、前記安全性証明情報を受信し、前記通信元装置からの接続要求に応じて、前記署名情報の付加された前記安全性証明情報を前記通信元装置へ送信し、
前記通信元装置は、前記通信相手装置に対する接続要求の後、前記通信相手装置から前記安全性証明情報を受信し、該安全性証明情報、および該安全性証明情報に付加された前記署名情報に基づいて前記通信相手装置の通信上の安全性を検証する
ことを特徴とする通信システム。
【請求項13】
前記安全性証明情報は、前記通信相手装置を特定する情報、前記安全性保証装置を特定する情報、前記安全性証明情報が生成された時を特定する情報、前記安全性証明情報の有効期限を示す情報、前記安全性証明情報を生成するためのアルゴリズムに関する諸情報、前記通信相手装置が、セキュリティ対策システムにより通信を監視していることを示す情報、該セキュリティ対策システムを特定する情報、および監視ポリシを示す情報からなる群の少なくとも1つを含むことを特徴とする請求項1または請求項12に記載の通信システム。
【請求項14】
前記通信元装置はさらに、前記安全性保証装置に前記安全性証明情報の有効性の判断を要求し、
前記安全性保証装置はさらに、前記通信元装置からの要求に応じて、前記安全性証明情報の有効性を判断する
ことを特徴とする請求項1または請求項12に記載の通信システム。
【請求項15】
前記安全性保証装置はさらに、セキュリティ対策の種別を示すセキュリティ対策情報と、前記セキュリティ対策情報の有効性を示す情報とが関連付けられた失効情報を記憶すると共に、前記通知情報に含まれる前記通信相手装置のセキュリティ対策情報を暗号化して前記安全性証明情報に付加し、前記通信相手装置へ前記安全性証明情報を送信し、前記通信元装置から前記安全性証明情報の有効性の判断を要求された場合に、前記安全性証明情報中の前記セキュリティ対策情報を復号化し、復号化後の前記セキュリティ対策情報と前記失効情報とに基づいて前記安全性証明情報の有効性を判断することを特徴とする請求項14に記載の通信システム。
【請求項16】
前記安全性保証装置はさらに、セキュリティ対策の種別を示すセキュリティ対策情報と、前記種別を識別する識別情報と、前記種別の有効性を示す情報とが関連付けられた失効情報を記憶すると共に、前記通知情報に含まれる前記通信相手装置のセキュリティ対策情報に対応した前記識別情報を前記安全性証明情報に付加して前記通信相手装置へ送信し、前記通信元装置から前記安全性証明情報の有効性の判断を要求された場合に、前記安全性証明情報中の前記識別情報と前記失効情報とに基づいて前記安全性証明情報の有効性を判断することを特徴とする請求項14に記載の通信システム。
【請求項17】
前記セキュリティ対策システムは、侵入検知システム、ウィルス検知システム、Firewall、および検疫システムからなる群の少なくとも1つからなることを特徴とする請求項4〜請求項6、請求項13のいずれかの項に記載の通信システム。
【請求項18】
前記通信相手装置は、セキュリティ対策システムを備え、
前記安全性保証装置は、最新の攻撃パターンを示すパターン情報に基づいた攻撃を前記通信相手装置に対して行い、
前記セキュリティ対策システムは、予め所持する前記パターン情報に基づいて、前記安全性保証装置による攻撃を検知し、
前記通信相手装置は、前記セキュリティ対策システムによって検知された攻撃を示す攻撃検知情報を前記安全性保証装置へ送信し、
前記安全性保証装置は、前記攻撃検知情報を受信し、前記攻撃検知情報および前記パターン情報に基づいて、前記通信相手装置の通信上の安全性を検証し、前記通信相手装置の通信上の安全性を確認した場合に、前記安全性証明情報に対して前記署名情報を付加して、前記通信相手装置へ送信する
ことを特徴とする請求項12に記載の通信システム。
【請求項19】
前記通信相手装置は、自身の通信上の安全性を通知するための通知情報に対して識別用のタグを付加した情報を含み、通信上の安全性を証明する安全性証明情報を前記安全性保証装置へ送信し、
前記安全性保証装置は、前記安全性証明情報を受信し、前記タグに基づいて前記通知情報を識別し、前記通知情報に基づいて前記通信相手装置の通信上の安全性を検証し、前記通信上の安全性を確認した場合に、前記安全性証明情報に対して署名情報を付加して、前記安全性証明情報を前記通信相手装置へ送信する
ことを特徴とする請求項12に記載の通信システム。
【請求項20】
前記通信相手装置は、自身が有するセキュリティ対策システムの状態を示す状態情報を含む前記安全性保証情報を前記安全性保証装置へ送信し、
前記安全性保証装置は、前記安全性保証情報を受信し、前記安全性保証情報に含まれる前記状態情報に基づいて前記通信相手装置の通信上の安全性を検証し、前記通信上の安全性を確認した場合に、前記安全性保証情報に対して署名情報を付加して、前記安全性保証情報を前記通信相手装置へ送信し、
前記通信相手装置において、前記セキュリティ対策システムの状態を確認する手段は、耐タンパ性を有するセキュリティチップ内に設けられている
ことを特徴とする請求項12に記載の通信システム。
【請求項21】
前記通信相手装置は、自身が有するセキュリティ対策システムの状態を示す状態情報を含む前記安全性保証情報を前記安全性保証装置へ送信し、
前記安全性保証装置は、前記安全性保証情報を受信し、前記安全性保証情報に含まれる前記状態情報に基づいて前記通信相手装置の通信上の安全性を検証し、前記通信上の安全性を確認した場合に、前記安全性保証情報に対して署名情報を付加して、前記安全性保証情報を前記通信相手装置へ送信し、
前記通信相手装置において、前記セキュリティ対策システムの状態を確認する手段のハッシュ値が、耐タンパ性を有するセキュリティチップ内に格納されている
ことを特徴とする請求項12に記載の通信システム。
【請求項22】
前記失効情報において、同一の前記種別に対して、異なる複数の前記識別情報が関連付けられていることを特徴とする請求項16に記載の通信システム。
【請求項23】
前記失効情報において、前記種別と、前記種別を識別する識別番号とが関連付けられており、前記識別番号の付与の際には、失効した前記種別に付与された前記識別番号以下の全識別番号と関連付けられている前記種別が失効している状態となるように、前記識別番号が付与されることを特徴とする請求項16に記載の通信システム。
【請求項24】
通信元装置と、該通信元装置からの接続要求に応じて、該通信元装置と通信を行う通信相手装置と、前記通信相手装置の通信上の安全性を保証する安全性保証装置とを具備する通信システムにおける安全性保証装置であって、
前記通信相手装置によって送信された、該通信相手装置の通信上の安全性を通知する通知情報を受信する受信手段と、
前記通知情報に基づいて前記通信相手装置の通信上の安全性を検証する検証手段と、
該検証手段によって前記通信相手装置の通信上の安全性が確認された場合に、該通信上の安全性を証明する安全性証明情報を生成する証明情報生成手段と、
該安全性証明情報を前記通信相手装置へ送信する送信手段と、
を具備することを特徴とする安全性保証装置。
【請求項25】
前記通信相手装置と両方向の認証を行い、該認証に続いて、前記通信相手装置を制御および操作する操作情報を前記通信相手装置へ送信し、該操作情報に基づいて前記通知情報を生成した前記通信相手装置から前記通知情報を受信すると共に、該通知情報に基づいて前記通信相手装置の通信上の安全性を検証することを特徴とする請求項24に記載の安全性保証装置。
【請求項26】
前記通信相手装置と両方向の認証を行い、該認証に続いて前記通知情報を生成した前記通信相手装置から前記通知情報を受信すると共に、該通知情報に基づいて前記通信相手装置の通信上の安全性を検証することを特徴とする請求項24に記載の安全性保証装置。
【請求項27】
最新の攻撃パターンを示すパターン情報に基づいた攻撃パケットを発生する攻撃発生手段をさらに具備し、
前記送信手段は、前記攻撃パケットを前記通信相手装置へ送信し、
前記受信手段は、前記通信相手装置が備えるセキュリティ対策システムによって検知された、前記攻撃パケットに基づいた攻撃を示す攻撃検知情報を前記通信相手装置から受信し、
前記検証手段は、前記通知情報に代えて、前記攻撃検知情報および前記パターン情報に基づいて、前記通信相手装置の通信上の安全性を検証する
ことを特徴とする請求項24に記載の安全性保証装置。
【請求項28】
前記通知情報は、前記通信相手装置がセキュリティ対策システムにより通信を監視している事実を示す情報を含むことを特徴とする請求項24に記載の安全性保証装置。
【請求項29】
前記受信手段はさらに、前記通信相手装置によって送信された、該通信相手装置の識別性を証明する識別性証明情報を受信し、
前記検証手段はさらに、前記識別性証明情報に基づいて前記通信相手装置の識別性を検証し、
前記証明情報生成手段は、前記検証手段によって前記通信相手装置の識別性および前記通信上の安全性が確認された場合に、前記安全性証明情報を生成する
ことを特徴とする請求項24に記載の安全性保証装置。
【請求項30】
前記通信相手装置によって送信された前記通知情報には、識別用のタグが付加されており、
前記証明情報生成手段は、前記タグに基づいて前記通知情報を識別し、前記通知情報に基づいて前記通信相手装置の通信上の安全性を検証し、前記通信上の安全性を確認した場合に、前記安全性証明情報を生成する
ことを特徴とする請求項24に記載の安全性保証装置。
【請求項31】
通信元装置と、該通信元装置からの接続要求に応じて、該通信元装置と通信を行う通信相手装置と、前記通信相手装置の通信上の安全性を保証する安全性保証装置とを具備する通信システムにおける安全性保証装置であって、
前記通信相手装置によって送信された、該通信相手装置の通信上の安全性を通知する安全性証明情報を受信する受信手段と、
前記安全性証明情報に対して署名情報を付加する署名情報付加手段と、
該署名情報が付加された前記安全性証明情報を前記通信相手装置へ送信する送信手段と、
を具備することを特徴とする安全性保証装置。
【請求項32】
前記通信元装置からの前記安全性証明情報の有効性の判断要求に応じて、前記安全性証明情報の有効性を判断する有効性判断手段をさらに具備することを特徴とする請求項24または請求項31に記載の安全性保証装置。
【請求項33】
前記安全性証明情報は、前記通信相手装置を特定する情報、前記安全性保証装置を特定する情報、前記安全性証明情報が生成された時を特定する情報、前記安全性証明情報の有効期限を示す情報、前記安全性証明情報を生成するためのアルゴリズムに関する諸情報、前記通信相手装置が、セキュリティ対策システムにより通信を監視していることを示す情報、該セキュリティ対策システムを特定する情報、および監視ポリシを示す情報からなる群の少なくとも1つを含むことを特徴とする請求項24または請求項31に記載の安全性保証装置。
【請求項34】
前記セキュリティ対策システムは、侵入検知システム、ウィルス検知システム、Firewall、および検疫システムからなる群の少なくとも1つからなることを特徴とする請求項27、請求項28、請求項33のいずれかの項に記載の安全性保証装置。
【請求項35】
最新の攻撃パターンを示すパターン情報に基づいた攻撃パケットを発生する攻撃発生手段をさらに具備し、
前記送信手段は、前記攻撃パケットを前記通信相手装置へ送信し、
前記受信手段は、前記通信相手装置が備えるセキュリティ対策システムによって検知された、前記攻撃パケットに基づいた攻撃を示す攻撃検知情報を前記通信相手装置から受信し、
前記検証手段は、前記攻撃検知情報および前記パターン情報に基づいて、前記通信相手装置の通信上の安全性を検証し、前記通信相手装置の通信上の安全性を確認した場合に、前記安全性証明情報に対して前記署名情報を付加して、前記通信相手装置へ送信する
ことを特徴とする請求項31に記載の安全性保証装置。
【請求項36】
セキュリティ対策の種別を示すセキュリティ対策情報と、前記セキュリティ対策情報の有効性を示す情報とが関連付けられた失効情報を記憶する記憶手段をさらに具備し、
前記証明情報生成手段はさらに、前記通知情報に含まれる前記通信相手装置のセキュリティ対策情報を暗号化して前記安全性証明情報に付加し、
前記有効性判断手段はさらに、前記通信元装置から前記安全性証明情報の有効性の判断を要求された場合に、前記安全性証明情報中の前記セキュリティ対策情報を復号化し、復号化後の前記セキュリティ対策情報と前記失効情報とに基づいて前記安全性証明情報の有効性を判断する
ことを特徴とする請求項32に記載の安全性保証装置。
【請求項37】
前記安全性保証装置はさらに、セキュリティ対策の種別を示すセキュリティ対策情報と、前記種別を識別する識別情報と、前記種別の有効性を示す情報とが関連付けられた失効情報を記憶する記憶手段をさらに具備し、
前記証明情報生成手段はさらに、前記通知情報に含まれる前記通信相手装置のセキュリティ対策情報に対応した前記識別情報を前記安全性証明情報に付加し、
前記有効性判断手段はさらに、前記通信元装置から前記安全性証明情報の有効性の判断を要求された場合に、前記安全性証明情報中の前記識別情報と前記失効情報とに基づいて前記安全性証明情報の有効性を判断する
ことを特徴とする請求項32に記載の安全性保証装置。
【請求項38】
前記失効情報において、同一の前記種別に対して、異なる複数の前記識別情報が関連付けられていることを特徴とする請求項37に記載の安全性保証装置。
【請求項39】
前記失効情報において、前記種別と、前記種別を識別する識別番号とが関連付けられており、前記識別番号の付与の際には、失効した前記種別に付与された前記識別番号以下の全識別番号と関連付けられている前記種別が失効している状態となるように、前記識別番号が付与されることを特徴とする請求項37に記載の安全性保証装置。
【請求項1】
通信元装置と、該通信元装置と通信を行う通信相手装置と、前記通信相手装置の通信上の安全性を保証する安全性保証装置とを具備する通信システムであって、
前記通信相手装置は、自身の通信上の安全性を通知するための通知情報を前記安全性保証装置へ送信し、
前記安全性保証装置は、前記通知情報を受信し、該通知情報に基づいて前記通信相手装置の通信上の安全性を検証し、該通信上の安全性を確認した場合に、該通信上の安全性を証明する安全性証明情報を生成して前記通信相手装置へ送信し、
前記通信相手装置は、前記安全性証明情報を受信し、前記通信元装置からの接続要求に応じて前記安全性証明情報を前記通信元装置へ送信し、
前記通信元装置は、前記通信相手装置に対する接続要求の後、前記通信相手装置から前記安全性証明情報を受信し、該安全性証明情報に基づいて前記通信相手装置の通信上の安全性を検証する
ことを特徴とする通信システム。
【請求項2】
前記通信相手装置および前記安全性保証装置は、両方向の認証を行い、
該認証に続いて前記安全性保証装置は、前記通信相手装置を制御および操作する操作情報を前記通信相手装置へ送信し、該操作情報に基づいて前記通知情報を生成した前記通信相手装置から前記通知情報を受信すると共に、該通知情報に基づいて前記通信相手装置の通信上の安全性を検証する
ことを特徴とする請求項1に記載の通信システム。
【請求項3】
前記通信相手装置および前記安全性保証装置は、両方向の認証を行い、
該認証に続いて前記通信相手装置は前記通知情報を生成して前記安全性保証装置へ送信し、
前記安全性保証装置は、前記通知情報を受信し、該通知情報に基づいて前記通信相手装置の通信上の安全性を検証する
ことを特徴とする請求項1に記載の通信システム。
【請求項4】
前記通信相手装置は、セキュリティ対策システムを備え、耐タンパ性を有するプログラムに従って、前記セキュリティ対策システムの状態を確認し、該状態に関する状態情報を生成して前記安全性保証装置へ送信し、
前記安全性保証装置は前記状態情報を受信し、前記通知情報および前記状態情報に基づいて前記通信相手装置の通信上の安全性を検証する
ことを特徴とする請求項1に記載の通信システム。
【請求項5】
前記通信相手装置は、セキュリティ対策システムを備え、
前記安全性保証装置は、最新の攻撃パターンを示すパターン情報に基づいた攻撃を前記通信相手装置に対して行い、
前記セキュリティ対策システムは、予め所持する前記パターン情報に基づいて、前記安全性保証装置による攻撃を検知し、
前記通信相手装置は、前記セキュリティ対策システムによって検知された攻撃を示す攻撃検知情報を前記安全性保証装置へ送信し、
前記安全性保証装置は、前記攻撃検知情報を受信し、前記通知情報に代えて、前記攻撃検知情報および前記パターン情報に基づいて、前記通信相手装置の通信上の安全性を検証する
ことを特徴とする請求項1に記載の通信システム。
【請求項6】
前記通信相手装置はセキュリティ対策システムを備え、前記通知情報は、前記セキュリティ対策システムにより通信を監視している事実を示す情報を含むことを特徴とする請求項1に記載の通信システム。
【請求項7】
前記通信相手装置はさらに、自身の識別性を証明する識別性証明情報を前記安全性保証装置へ送信し、
前記安全性保証装置はさらに、前記識別性情報を受信し、該識別性証明情報に基づいて前記通信相手装置の識別性を検証し、前記通信相手装置の識別性および前記通信上の安全性を確認した場合に、前記安全性証明情報を生成して前記通信相手装置へ送信する
ことを特徴とする請求項1に記載の通信システム。
【請求項8】
前記通信相手装置はさらに、前記通信元装置からの接続要求に応じて、自身の識別性を証明する識別性証明情報を前記通信元装置へ送信し、
前記通信元装置はさらに、前記通信相手装置に対する接続要求の後、前記通信相手装置から前記識別性証明情報を受信し、該識別性証明情報に基づいて、前記通信相手装置の識別性を検証する
ことを特徴とする請求項1に記載の通信システム。
【請求項9】
前記通信相手装置は、前記通知情報に対して、識別用のタグを付加して前記安全性保証装置へ送信し、
前記安全性保証装置は、前記通知情報を受信し、前記タグに基づいて前記通知情報を識別し、前記通知情報に基づいて前記通信相手装置の通信上の安全性を検証し、前記通信上の安全性を確認した場合に、前記安全性証明情報を前記通信相手装置へ送信する
ことを特徴とする請求項1に記載の通信システム。
【請求項10】
前記通信相手装置は、自身が有するセキュリティ対策システムの状態を確認し、前記状態を示す状態情報を前記安全性保証装置へ送信し、
前記安全性保証装置は、前記状態情報を受信し、前記状態情報に基づいて前記通信相手装置の通信上の安全性を検証し、前記通信上の安全性を確認した場合に、前記安全性証明情報を生成して前記通信相手装置へ送信し、
前記通信相手装置において、前記セキュリティ対策システムの状態を確認する手段は、耐タンパ性を有するセキュリティチップ内に設けられている
ことを特徴とする請求項1に記載の通信システム。
【請求項11】
前記通信相手装置は、自身が有するセキュリティ対策システムの状態を確認し、前記状態を示す状態情報を前記安全性保証装置へ送信し、
前記安全性保証装置は、前記状態情報を受信し、前記状態情報に基づいて前記通信相手装置の通信上の安全性を検証し、前記通信上の安全性を確認した場合に、前記安全性証明情報を生成して前記通信相手装置へ送信し、
前記通信相手装置において、前記セキュリティ対策システムの状態を確認する手段のハッシュ値が、耐タンパ性を有するセキュリティチップ内に格納されている
ことを特徴とする請求項1に記載の通信システム。
【請求項12】
通信元装置と、該通信元装置と通信を行う通信相手装置と、前記通信相手装置の通信上の安全性を保証する安全性保証装置とを具備する通信システムであって、
前記通信相手装置は、自身の通信上の安全性を証明する安全性証明情報を前記安全性保証装置へ送信し、
前記安全性保証装置は、前記安全性証明情報を受信し、該安全性証明情報に対して署名情報を付加して、前記安全性証明情報を前記通信相手装置へ送信し、
前記通信相手装置は、前記安全性証明情報を受信し、前記通信元装置からの接続要求に応じて、前記署名情報の付加された前記安全性証明情報を前記通信元装置へ送信し、
前記通信元装置は、前記通信相手装置に対する接続要求の後、前記通信相手装置から前記安全性証明情報を受信し、該安全性証明情報、および該安全性証明情報に付加された前記署名情報に基づいて前記通信相手装置の通信上の安全性を検証する
ことを特徴とする通信システム。
【請求項13】
前記安全性証明情報は、前記通信相手装置を特定する情報、前記安全性保証装置を特定する情報、前記安全性証明情報が生成された時を特定する情報、前記安全性証明情報の有効期限を示す情報、前記安全性証明情報を生成するためのアルゴリズムに関する諸情報、前記通信相手装置が、セキュリティ対策システムにより通信を監視していることを示す情報、該セキュリティ対策システムを特定する情報、および監視ポリシを示す情報からなる群の少なくとも1つを含むことを特徴とする請求項1または請求項12に記載の通信システム。
【請求項14】
前記通信元装置はさらに、前記安全性保証装置に前記安全性証明情報の有効性の判断を要求し、
前記安全性保証装置はさらに、前記通信元装置からの要求に応じて、前記安全性証明情報の有効性を判断する
ことを特徴とする請求項1または請求項12に記載の通信システム。
【請求項15】
前記安全性保証装置はさらに、セキュリティ対策の種別を示すセキュリティ対策情報と、前記セキュリティ対策情報の有効性を示す情報とが関連付けられた失効情報を記憶すると共に、前記通知情報に含まれる前記通信相手装置のセキュリティ対策情報を暗号化して前記安全性証明情報に付加し、前記通信相手装置へ前記安全性証明情報を送信し、前記通信元装置から前記安全性証明情報の有効性の判断を要求された場合に、前記安全性証明情報中の前記セキュリティ対策情報を復号化し、復号化後の前記セキュリティ対策情報と前記失効情報とに基づいて前記安全性証明情報の有効性を判断することを特徴とする請求項14に記載の通信システム。
【請求項16】
前記安全性保証装置はさらに、セキュリティ対策の種別を示すセキュリティ対策情報と、前記種別を識別する識別情報と、前記種別の有効性を示す情報とが関連付けられた失効情報を記憶すると共に、前記通知情報に含まれる前記通信相手装置のセキュリティ対策情報に対応した前記識別情報を前記安全性証明情報に付加して前記通信相手装置へ送信し、前記通信元装置から前記安全性証明情報の有効性の判断を要求された場合に、前記安全性証明情報中の前記識別情報と前記失効情報とに基づいて前記安全性証明情報の有効性を判断することを特徴とする請求項14に記載の通信システム。
【請求項17】
前記セキュリティ対策システムは、侵入検知システム、ウィルス検知システム、Firewall、および検疫システムからなる群の少なくとも1つからなることを特徴とする請求項4〜請求項6、請求項13のいずれかの項に記載の通信システム。
【請求項18】
前記通信相手装置は、セキュリティ対策システムを備え、
前記安全性保証装置は、最新の攻撃パターンを示すパターン情報に基づいた攻撃を前記通信相手装置に対して行い、
前記セキュリティ対策システムは、予め所持する前記パターン情報に基づいて、前記安全性保証装置による攻撃を検知し、
前記通信相手装置は、前記セキュリティ対策システムによって検知された攻撃を示す攻撃検知情報を前記安全性保証装置へ送信し、
前記安全性保証装置は、前記攻撃検知情報を受信し、前記攻撃検知情報および前記パターン情報に基づいて、前記通信相手装置の通信上の安全性を検証し、前記通信相手装置の通信上の安全性を確認した場合に、前記安全性証明情報に対して前記署名情報を付加して、前記通信相手装置へ送信する
ことを特徴とする請求項12に記載の通信システム。
【請求項19】
前記通信相手装置は、自身の通信上の安全性を通知するための通知情報に対して識別用のタグを付加した情報を含み、通信上の安全性を証明する安全性証明情報を前記安全性保証装置へ送信し、
前記安全性保証装置は、前記安全性証明情報を受信し、前記タグに基づいて前記通知情報を識別し、前記通知情報に基づいて前記通信相手装置の通信上の安全性を検証し、前記通信上の安全性を確認した場合に、前記安全性証明情報に対して署名情報を付加して、前記安全性証明情報を前記通信相手装置へ送信する
ことを特徴とする請求項12に記載の通信システム。
【請求項20】
前記通信相手装置は、自身が有するセキュリティ対策システムの状態を示す状態情報を含む前記安全性保証情報を前記安全性保証装置へ送信し、
前記安全性保証装置は、前記安全性保証情報を受信し、前記安全性保証情報に含まれる前記状態情報に基づいて前記通信相手装置の通信上の安全性を検証し、前記通信上の安全性を確認した場合に、前記安全性保証情報に対して署名情報を付加して、前記安全性保証情報を前記通信相手装置へ送信し、
前記通信相手装置において、前記セキュリティ対策システムの状態を確認する手段は、耐タンパ性を有するセキュリティチップ内に設けられている
ことを特徴とする請求項12に記載の通信システム。
【請求項21】
前記通信相手装置は、自身が有するセキュリティ対策システムの状態を示す状態情報を含む前記安全性保証情報を前記安全性保証装置へ送信し、
前記安全性保証装置は、前記安全性保証情報を受信し、前記安全性保証情報に含まれる前記状態情報に基づいて前記通信相手装置の通信上の安全性を検証し、前記通信上の安全性を確認した場合に、前記安全性保証情報に対して署名情報を付加して、前記安全性保証情報を前記通信相手装置へ送信し、
前記通信相手装置において、前記セキュリティ対策システムの状態を確認する手段のハッシュ値が、耐タンパ性を有するセキュリティチップ内に格納されている
ことを特徴とする請求項12に記載の通信システム。
【請求項22】
前記失効情報において、同一の前記種別に対して、異なる複数の前記識別情報が関連付けられていることを特徴とする請求項16に記載の通信システム。
【請求項23】
前記失効情報において、前記種別と、前記種別を識別する識別番号とが関連付けられており、前記識別番号の付与の際には、失効した前記種別に付与された前記識別番号以下の全識別番号と関連付けられている前記種別が失効している状態となるように、前記識別番号が付与されることを特徴とする請求項16に記載の通信システム。
【請求項24】
通信元装置と、該通信元装置からの接続要求に応じて、該通信元装置と通信を行う通信相手装置と、前記通信相手装置の通信上の安全性を保証する安全性保証装置とを具備する通信システムにおける安全性保証装置であって、
前記通信相手装置によって送信された、該通信相手装置の通信上の安全性を通知する通知情報を受信する受信手段と、
前記通知情報に基づいて前記通信相手装置の通信上の安全性を検証する検証手段と、
該検証手段によって前記通信相手装置の通信上の安全性が確認された場合に、該通信上の安全性を証明する安全性証明情報を生成する証明情報生成手段と、
該安全性証明情報を前記通信相手装置へ送信する送信手段と、
を具備することを特徴とする安全性保証装置。
【請求項25】
前記通信相手装置と両方向の認証を行い、該認証に続いて、前記通信相手装置を制御および操作する操作情報を前記通信相手装置へ送信し、該操作情報に基づいて前記通知情報を生成した前記通信相手装置から前記通知情報を受信すると共に、該通知情報に基づいて前記通信相手装置の通信上の安全性を検証することを特徴とする請求項24に記載の安全性保証装置。
【請求項26】
前記通信相手装置と両方向の認証を行い、該認証に続いて前記通知情報を生成した前記通信相手装置から前記通知情報を受信すると共に、該通知情報に基づいて前記通信相手装置の通信上の安全性を検証することを特徴とする請求項24に記載の安全性保証装置。
【請求項27】
最新の攻撃パターンを示すパターン情報に基づいた攻撃パケットを発生する攻撃発生手段をさらに具備し、
前記送信手段は、前記攻撃パケットを前記通信相手装置へ送信し、
前記受信手段は、前記通信相手装置が備えるセキュリティ対策システムによって検知された、前記攻撃パケットに基づいた攻撃を示す攻撃検知情報を前記通信相手装置から受信し、
前記検証手段は、前記通知情報に代えて、前記攻撃検知情報および前記パターン情報に基づいて、前記通信相手装置の通信上の安全性を検証する
ことを特徴とする請求項24に記載の安全性保証装置。
【請求項28】
前記通知情報は、前記通信相手装置がセキュリティ対策システムにより通信を監視している事実を示す情報を含むことを特徴とする請求項24に記載の安全性保証装置。
【請求項29】
前記受信手段はさらに、前記通信相手装置によって送信された、該通信相手装置の識別性を証明する識別性証明情報を受信し、
前記検証手段はさらに、前記識別性証明情報に基づいて前記通信相手装置の識別性を検証し、
前記証明情報生成手段は、前記検証手段によって前記通信相手装置の識別性および前記通信上の安全性が確認された場合に、前記安全性証明情報を生成する
ことを特徴とする請求項24に記載の安全性保証装置。
【請求項30】
前記通信相手装置によって送信された前記通知情報には、識別用のタグが付加されており、
前記証明情報生成手段は、前記タグに基づいて前記通知情報を識別し、前記通知情報に基づいて前記通信相手装置の通信上の安全性を検証し、前記通信上の安全性を確認した場合に、前記安全性証明情報を生成する
ことを特徴とする請求項24に記載の安全性保証装置。
【請求項31】
通信元装置と、該通信元装置からの接続要求に応じて、該通信元装置と通信を行う通信相手装置と、前記通信相手装置の通信上の安全性を保証する安全性保証装置とを具備する通信システムにおける安全性保証装置であって、
前記通信相手装置によって送信された、該通信相手装置の通信上の安全性を通知する安全性証明情報を受信する受信手段と、
前記安全性証明情報に対して署名情報を付加する署名情報付加手段と、
該署名情報が付加された前記安全性証明情報を前記通信相手装置へ送信する送信手段と、
を具備することを特徴とする安全性保証装置。
【請求項32】
前記通信元装置からの前記安全性証明情報の有効性の判断要求に応じて、前記安全性証明情報の有効性を判断する有効性判断手段をさらに具備することを特徴とする請求項24または請求項31に記載の安全性保証装置。
【請求項33】
前記安全性証明情報は、前記通信相手装置を特定する情報、前記安全性保証装置を特定する情報、前記安全性証明情報が生成された時を特定する情報、前記安全性証明情報の有効期限を示す情報、前記安全性証明情報を生成するためのアルゴリズムに関する諸情報、前記通信相手装置が、セキュリティ対策システムにより通信を監視していることを示す情報、該セキュリティ対策システムを特定する情報、および監視ポリシを示す情報からなる群の少なくとも1つを含むことを特徴とする請求項24または請求項31に記載の安全性保証装置。
【請求項34】
前記セキュリティ対策システムは、侵入検知システム、ウィルス検知システム、Firewall、および検疫システムからなる群の少なくとも1つからなることを特徴とする請求項27、請求項28、請求項33のいずれかの項に記載の安全性保証装置。
【請求項35】
最新の攻撃パターンを示すパターン情報に基づいた攻撃パケットを発生する攻撃発生手段をさらに具備し、
前記送信手段は、前記攻撃パケットを前記通信相手装置へ送信し、
前記受信手段は、前記通信相手装置が備えるセキュリティ対策システムによって検知された、前記攻撃パケットに基づいた攻撃を示す攻撃検知情報を前記通信相手装置から受信し、
前記検証手段は、前記攻撃検知情報および前記パターン情報に基づいて、前記通信相手装置の通信上の安全性を検証し、前記通信相手装置の通信上の安全性を確認した場合に、前記安全性証明情報に対して前記署名情報を付加して、前記通信相手装置へ送信する
ことを特徴とする請求項31に記載の安全性保証装置。
【請求項36】
セキュリティ対策の種別を示すセキュリティ対策情報と、前記セキュリティ対策情報の有効性を示す情報とが関連付けられた失効情報を記憶する記憶手段をさらに具備し、
前記証明情報生成手段はさらに、前記通知情報に含まれる前記通信相手装置のセキュリティ対策情報を暗号化して前記安全性証明情報に付加し、
前記有効性判断手段はさらに、前記通信元装置から前記安全性証明情報の有効性の判断を要求された場合に、前記安全性証明情報中の前記セキュリティ対策情報を復号化し、復号化後の前記セキュリティ対策情報と前記失効情報とに基づいて前記安全性証明情報の有効性を判断する
ことを特徴とする請求項32に記載の安全性保証装置。
【請求項37】
前記安全性保証装置はさらに、セキュリティ対策の種別を示すセキュリティ対策情報と、前記種別を識別する識別情報と、前記種別の有効性を示す情報とが関連付けられた失効情報を記憶する記憶手段をさらに具備し、
前記証明情報生成手段はさらに、前記通知情報に含まれる前記通信相手装置のセキュリティ対策情報に対応した前記識別情報を前記安全性証明情報に付加し、
前記有効性判断手段はさらに、前記通信元装置から前記安全性証明情報の有効性の判断を要求された場合に、前記安全性証明情報中の前記識別情報と前記失効情報とに基づいて前記安全性証明情報の有効性を判断する
ことを特徴とする請求項32に記載の安全性保証装置。
【請求項38】
前記失効情報において、同一の前記種別に対して、異なる複数の前記識別情報が関連付けられていることを特徴とする請求項37に記載の安全性保証装置。
【請求項39】
前記失効情報において、前記種別と、前記種別を識別する識別番号とが関連付けられており、前記識別番号の付与の際には、失効した前記種別に付与された前記識別番号以下の全識別番号と関連付けられている前記種別が失効している状態となるように、前記識別番号が付与されることを特徴とする請求項37に記載の安全性保証装置。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【公開番号】特開2006−139747(P2006−139747A)
【公開日】平成18年6月1日(2006.6.1)
【国際特許分類】
【出願番号】特願2005−77247(P2005−77247)
【出願日】平成17年3月17日(2005.3.17)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.Linux
【出願人】(000208891)KDDI株式会社 (2,700)
【出願人】(899000079)学校法人慶應義塾 (742)
【Fターム(参考)】
【公開日】平成18年6月1日(2006.6.1)
【国際特許分類】
【出願日】平成17年3月17日(2005.3.17)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.Linux
【出願人】(000208891)KDDI株式会社 (2,700)
【出願人】(899000079)学校法人慶應義塾 (742)
【Fターム(参考)】
[ Back to top ]