(57)【要約】 【課題】  通信相手がセキュリティ対策を施していることを保証することができる通信システムおよび安全性保証装置を提供する。【解決手段】  サーバ３は、ＡＣの発行に必要な情報１０４をセキュリティ保証局２へ送信する。セキュリティ保証局２は、ＡＣの発行に必要な情報１０４に基づいてサーバ３の通信上の安全性を検証する。セキュリティ保証局２は、サーバ３の通信上の安全性を確認した場合に、サーバ３の通信上の安全性を証明するＡＣ１０５を発行し、サーバ３へ送信する。サーバ３はＡＣ１０５を受信し、クライアント４からの接続要求に応じてＡＣ１０５をクライアント４へ送信する。クライアント４は、ＡＣ１０５を受信し、ＡＣ１０５に基づいて、サーバ３の通信上の安全性を検証する。【選択図】    図１
2006139747.tif 000002
【特許請求の範囲】
【請求項１】
通信元装置と、該通信元装置と通信を行う通信相手装置と、前記通信相手装置の通信上の安全性を保証する安全性保証装置とを具備する通信システムであって、
前記通信相手装置は、自身の通信上の安全性を通知するための通知情報を前記安全性保証装置へ送信し、
前記安全性保証装置は、前記通知情報を受信し、該通知情報に基づいて前記通信相手装置の通信上の安全性を検証し、該通信上の安全性を確認した場合に、該通信上の安全性を証明する安全性証明情報を生成して前記通信相手装置へ送信し、
前記通信相手装置は、前記安全性証明情報を受信し、前記通信元装置からの接続要求に応じて前記安全性証明情報を前記通信元装置へ送信し、
前記通信元装置は、前記通信相手装置に対する接続要求の後、前記通信相手装置から前記安全性証明情報を受信し、該安全性証明情報に基づいて前記通信相手装置の通信上の安全性を検証する
ことを特徴とする通信システム。
【請求項２】
前記通信相手装置および前記安全性保証装置は、両方向の認証を行い、
該認証に続いて前記安全性保証装置は、前記通信相手装置を制御および操作する操作情報を前記通信相手装置へ送信し、該操作情報に基づいて前記通知情報を生成した前記通信相手装置から前記通知情報を受信すると共に、該通知情報に基づいて前記通信相手装置の通信上の安全性を検証する
ことを特徴とする請求項１に記載の通信システム。
【請求項３】
前記通信相手装置および前記安全性保証装置は、両方向の認証を行い、
該認証に続いて前記通信相手装置は前記通知情報を生成して前記安全性保証装置へ送信し、
前記安全性保証装置は、前記通知情報を受信し、該通知情報に基づいて前記通信相手装置の通信上の安全性を検証する
ことを特徴とする請求項１に記載の通信システム。
【請求項４】
前記通信相手装置は、セキュリティ対策システムを備え、耐タンパ性を有するプログラムに従って、前記セキュリティ対策システムの状態を確認し、該状態に関する状態情報を生成して前記安全性保証装置へ送信し、
前記安全性保証装置は前記状態情報を受信し、前記通知情報および前記状態情報に基づいて前記通信相手装置の通信上の安全性を検証する
ことを特徴とする請求項１に記載の通信システム。
【請求項５】
前記通信相手装置は、セキュリティ対策システムを備え、
前記安全性保証装置は、最新の攻撃パターンを示すパターン情報に基づいた攻撃を前記通信相手装置に対して行い、
前記セキュリティ対策システムは、予め所持する前記パターン情報に基づいて、前記安全性保証装置による攻撃を検知し、
前記通信相手装置は、前記セキュリティ対策システムによって検知された攻撃を示す攻撃検知情報を前記安全性保証装置へ送信し、
前記安全性保証装置は、前記攻撃検知情報を受信し、前記通知情報に代えて、前記攻撃検知情報および前記パターン情報に基づいて、前記通信相手装置の通信上の安全性を検証する
ことを特徴とする請求項１に記載の通信システム。
【請求項６】
前記通信相手装置はセキュリティ対策システムを備え、前記通知情報は、前記セキュリティ対策システムにより通信を監視している事実を示す情報を含むことを特徴とする請求項１に記載の通信システム。
【請求項７】
前記通信相手装置はさらに、自身の識別性を証明する識別性証明情報を前記安全性保証装置へ送信し、
前記安全性保証装置はさらに、前記識別性情報を受信し、該識別性証明情報に基づいて前記通信相手装置の識別性を検証し、前記通信相手装置の識別性および前記通信上の安全性を確認した場合に、前記安全性証明情報を生成して前記通信相手装置へ送信する
ことを特徴とする請求項１に記載の通信システム。
【請求項８】
前記通信相手装置はさらに、前記通信元装置からの接続要求に応じて、自身の識別性を証明する識別性証明情報を前記通信元装置へ送信し、
前記通信元装置はさらに、前記通信相手装置に対する接続要求の後、前記通信相手装置から前記識別性証明情報を受信し、該識別性証明情報に基づいて、前記通信相手装置の識別性を検証する
ことを特徴とする請求項１に記載の通信システム。
【請求項９】
前記通信相手装置は、前記通知情報に対して、識別用のタグを付加して前記安全性保証装置へ送信し、
前記安全性保証装置は、前記通知情報を受信し、前記タグに基づいて前記通知情報を識別し、前記通知情報に基づいて前記通信相手装置の通信上の安全性を検証し、前記通信上の安全性を確認した場合に、前記安全性証明情報を前記通信相手装置へ送信する
ことを特徴とする請求項１に記載の通信システム。
【請求項１０】
前記通信相手装置は、自身が有するセキュリティ対策システムの状態を確認し、前記状態を示す状態情報を前記安全性保証装置へ送信し、
前記安全性保証装置は、前記状態情報を受信し、前記状態情報に基づいて前記通信相手装置の通信上の安全性を検証し、前記通信上の安全性を確認した場合に、前記安全性証明情報を生成して前記通信相手装置へ送信し、
前記通信相手装置において、前記セキュリティ対策システムの状態を確認する手段は、耐タンパ性を有するセキュリティチップ内に設けられている
ことを特徴とする請求項１に記載の通信システム。
【請求項１１】
前記通信相手装置は、自身が有するセキュリティ対策システムの状態を確認し、前記状態を示す状態情報を前記安全性保証装置へ送信し、
前記安全性保証装置は、前記状態情報を受信し、前記状態情報に基づいて前記通信相手装置の通信上の安全性を検証し、前記通信上の安全性を確認した場合に、前記安全性証明情報を生成して前記通信相手装置へ送信し、
前記通信相手装置において、前記セキュリティ対策システムの状態を確認する手段のハッシュ値が、耐タンパ性を有するセキュリティチップ内に格納されている
ことを特徴とする請求項１に記載の通信システム。
【請求項１２】
通信元装置と、該通信元装置と通信を行う通信相手装置と、前記通信相手装置の通信上の安全性を保証する安全性保証装置とを具備する通信システムであって、
前記通信相手装置は、自身の通信上の安全性を証明する安全性証明情報を前記安全性保証装置へ送信し、
前記安全性保証装置は、前記安全性証明情報を受信し、該安全性証明情報に対して署名情報を付加して、前記安全性証明情報を前記通信相手装置へ送信し、
前記通信相手装置は、前記安全性証明情報を受信し、前記通信元装置からの接続要求に応じて、前記署名情報の付加された前記安全性証明情報を前記通信元装置へ送信し、
前記通信元装置は、前記通信相手装置に対する接続要求の後、前記通信相手装置から前記安全性証明情報を受信し、該安全性証明情報、および該安全性証明情報に付加された前記署名情報に基づいて前記通信相手装置の通信上の安全性を検証する
ことを特徴とする通信システム。
【請求項１３】
前記安全性証明情報は、前記通信相手装置を特定する情報、前記安全性保証装置を特定する情報、前記安全性証明情報が生成された時を特定する情報、前記安全性証明情報の有効期限を示す情報、前記安全性証明情報を生成するためのアルゴリズムに関する諸情報、前記通信相手装置が、セキュリティ対策システムにより通信を監視していることを示す情報、該セキュリティ対策システムを特定する情報、および監視ポリシを示す情報からなる群の少なくとも１つを含むことを特徴とする請求項１または請求項１２に記載の通信システム。
【請求項１４】
前記通信元装置はさらに、前記安全性保証装置に前記安全性証明情報の有効性の判断を要求し、
前記安全性保証装置はさらに、前記通信元装置からの要求に応じて、前記安全性証明情報の有効性を判断する
ことを特徴とする請求項１または請求項１２に記載の通信システム。
【請求項１５】
前記安全性保証装置はさらに、セキュリティ対策の種別を示すセキュリティ対策情報と、前記セキュリティ対策情報の有効性を示す情報とが関連付けられた失効情報を記憶すると共に、前記通知情報に含まれる前記通信相手装置のセキュリティ対策情報を暗号化して前記安全性証明情報に付加し、前記通信相手装置へ前記安全性証明情報を送信し、前記通信元装置から前記安全性証明情報の有効性の判断を要求された場合に、前記安全性証明情報中の前記セキュリティ対策情報を復号化し、復号化後の前記セキュリティ対策情報と前記失効情報とに基づいて前記安全性証明情報の有効性を判断することを特徴とする請求項１４に記載の通信システム。
【請求項１６】
前記安全性保証装置はさらに、セキュリティ対策の種別を示すセキュリティ対策情報と、前記種別を識別する識別情報と、前記種別の有効性を示す情報とが関連付けられた失効情報を記憶すると共に、前記通知情報に含まれる前記通信相手装置のセキュリティ対策情報に対応した前記識別情報を前記安全性証明情報に付加して前記通信相手装置へ送信し、前記通信元装置から前記安全性証明情報の有効性の判断を要求された場合に、前記安全性証明情報中の前記識別情報と前記失効情報とに基づいて前記安全性証明情報の有効性を判断することを特徴とする請求項１４に記載の通信システム。
【請求項１７】
前記セキュリティ対策システムは、侵入検知システム、ウィルス検知システム、Ｆｉｒｅｗａｌｌ、および検疫システムからなる群の少なくとも１つからなることを特徴とする請求項４〜請求項６、請求項１３のいずれかの項に記載の通信システム。
【請求項１８】
前記通信相手装置は、セキュリティ対策システムを備え、
前記安全性保証装置は、最新の攻撃パターンを示すパターン情報に基づいた攻撃を前記通信相手装置に対して行い、
前記セキュリティ対策システムは、予め所持する前記パターン情報に基づいて、前記安全性保証装置による攻撃を検知し、
前記通信相手装置は、前記セキュリティ対策システムによって検知された攻撃を示す攻撃検知情報を前記安全性保証装置へ送信し、
前記安全性保証装置は、前記攻撃検知情報を受信し、前記攻撃検知情報および前記パターン情報に基づいて、前記通信相手装置の通信上の安全性を検証し、前記通信相手装置の通信上の安全性を確認した場合に、前記安全性証明情報に対して前記署名情報を付加して、前記通信相手装置へ送信する
ことを特徴とする請求項１２に記載の通信システム。
【請求項１９】
前記通信相手装置は、自身の通信上の安全性を通知するための通知情報に対して識別用のタグを付加した情報を含み、通信上の安全性を証明する安全性証明情報を前記安全性保証装置へ送信し、
前記安全性保証装置は、前記安全性証明情報を受信し、前記タグに基づいて前記通知情報を識別し、前記通知情報に基づいて前記通信相手装置の通信上の安全性を検証し、前記通信上の安全性を確認した場合に、前記安全性証明情報に対して署名情報を付加して、前記安全性証明情報を前記通信相手装置へ送信する
ことを特徴とする請求項１２に記載の通信システム。
【請求項２０】
前記通信相手装置は、自身が有するセキュリティ対策システムの状態を示す状態情報を含む前記安全性保証情報を前記安全性保証装置へ送信し、
前記安全性保証装置は、前記安全性保証情報を受信し、前記安全性保証情報に含まれる前記状態情報に基づいて前記通信相手装置の通信上の安全性を検証し、前記通信上の安全性を確認した場合に、前記安全性保証情報に対して署名情報を付加して、前記安全性保証情報を前記通信相手装置へ送信し、
前記通信相手装置において、前記セキュリティ対策システムの状態を確認する手段は、耐タンパ性を有するセキュリティチップ内に設けられている
ことを特徴とする請求項１２に記載の通信システム。
【請求項２１】
前記通信相手装置は、自身が有するセキュリティ対策システムの状態を示す状態情報を含む前記安全性保証情報を前記安全性保証装置へ送信し、
前記安全性保証装置は、前記安全性保証情報を受信し、前記安全性保証情報に含まれる前記状態情報に基づいて前記通信相手装置の通信上の安全性を検証し、前記通信上の安全性を確認した場合に、前記安全性保証情報に対して署名情報を付加して、前記安全性保証情報を前記通信相手装置へ送信し、
前記通信相手装置において、前記セキュリティ対策システムの状態を確認する手段のハッシュ値が、耐タンパ性を有するセキュリティチップ内に格納されている
ことを特徴とする請求項１２に記載の通信システム。
【請求項２２】
前記失効情報において、同一の前記種別に対して、異なる複数の前記識別情報が関連付けられていることを特徴とする請求項１６に記載の通信システム。
【請求項２３】
前記失効情報において、前記種別と、前記種別を識別する識別番号とが関連付けられており、前記識別番号の付与の際には、失効した前記種別に付与された前記識別番号以下の全識別番号と関連付けられている前記種別が失効している状態となるように、前記識別番号が付与されることを特徴とする請求項１６に記載の通信システム。
【請求項２４】
通信元装置と、該通信元装置からの接続要求に応じて、該通信元装置と通信を行う通信相手装置と、前記通信相手装置の通信上の安全性を保証する安全性保証装置とを具備する通信システムにおける安全性保証装置であって、
前記通信相手装置によって送信された、該通信相手装置の通信上の安全性を通知する通知情報を受信する受信手段と、
前記通知情報に基づいて前記通信相手装置の通信上の安全性を検証する検証手段と、
該検証手段によって前記通信相手装置の通信上の安全性が確認された場合に、該通信上の安全性を証明する安全性証明情報を生成する証明情報生成手段と、
該安全性証明情報を前記通信相手装置へ送信する送信手段と、
を具備することを特徴とする安全性保証装置。
【請求項２５】
前記通信相手装置と両方向の認証を行い、該認証に続いて、前記通信相手装置を制御および操作する操作情報を前記通信相手装置へ送信し、該操作情報に基づいて前記通知情報を生成した前記通信相手装置から前記通知情報を受信すると共に、該通知情報に基づいて前記通信相手装置の通信上の安全性を検証することを特徴とする請求項２４に記載の安全性保証装置。
【請求項２６】
前記通信相手装置と両方向の認証を行い、該認証に続いて前記通知情報を生成した前記通信相手装置から前記通知情報を受信すると共に、該通知情報に基づいて前記通信相手装置の通信上の安全性を検証することを特徴とする請求項２４に記載の安全性保証装置。
【請求項２７】
最新の攻撃パターンを示すパターン情報に基づいた攻撃パケットを発生する攻撃発生手段をさらに具備し、
前記送信手段は、前記攻撃パケットを前記通信相手装置へ送信し、
前記受信手段は、前記通信相手装置が備えるセキュリティ対策システムによって検知された、前記攻撃パケットに基づいた攻撃を示す攻撃検知情報を前記通信相手装置から受信し、
前記検証手段は、前記通知情報に代えて、前記攻撃検知情報および前記パターン情報に基づいて、前記通信相手装置の通信上の安全性を検証する
ことを特徴とする請求項２４に記載の安全性保証装置。
【請求項２８】
前記通知情報は、前記通信相手装置がセキュリティ対策システムにより通信を監視している事実を示す情報を含むことを特徴とする請求項２４に記載の安全性保証装置。
【請求項２９】
前記受信手段はさらに、前記通信相手装置によって送信された、該通信相手装置の識別性を証明する識別性証明情報を受信し、
前記検証手段はさらに、前記識別性証明情報に基づいて前記通信相手装置の識別性を検証し、
前記証明情報生成手段は、前記検証手段によって前記通信相手装置の識別性および前記通信上の安全性が確認された場合に、前記安全性証明情報を生成する
ことを特徴とする請求項２４に記載の安全性保証装置。
【請求項３０】
前記通信相手装置によって送信された前記通知情報には、識別用のタグが付加されており、
前記証明情報生成手段は、前記タグに基づいて前記通知情報を識別し、前記通知情報に基づいて前記通信相手装置の通信上の安全性を検証し、前記通信上の安全性を確認した場合に、前記安全性証明情報を生成する
ことを特徴とする請求項２４に記載の安全性保証装置。
【請求項３１】
通信元装置と、該通信元装置からの接続要求に応じて、該通信元装置と通信を行う通信相手装置と、前記通信相手装置の通信上の安全性を保証する安全性保証装置とを具備する通信システムにおける安全性保証装置であって、
前記通信相手装置によって送信された、該通信相手装置の通信上の安全性を通知する安全性証明情報を受信する受信手段と、
前記安全性証明情報に対して署名情報を付加する署名情報付加手段と、
該署名情報が付加された前記安全性証明情報を前記通信相手装置へ送信する送信手段と、
を具備することを特徴とする安全性保証装置。
【請求項３２】
前記通信元装置からの前記安全性証明情報の有効性の判断要求に応じて、前記安全性証明情報の有効性を判断する有効性判断手段をさらに具備することを特徴とする請求項２４または請求項３１に記載の安全性保証装置。
【請求項３３】
前記安全性証明情報は、前記通信相手装置を特定する情報、前記安全性保証装置を特定する情報、前記安全性証明情報が生成された時を特定する情報、前記安全性証明情報の有効期限を示す情報、前記安全性証明情報を生成するためのアルゴリズムに関する諸情報、前記通信相手装置が、セキュリティ対策システムにより通信を監視していることを示す情報、該セキュリティ対策システムを特定する情報、および監視ポリシを示す情報からなる群の少なくとも１つを含むことを特徴とする請求項２４または請求項３１に記載の安全性保証装置。
【請求項３４】
前記セキュリティ対策システムは、侵入検知システム、ウィルス検知システム、Ｆｉｒｅｗａｌｌ、および検疫システムからなる群の少なくとも１つからなることを特徴とする請求項２７、請求項２８、請求項３３のいずれかの項に記載の安全性保証装置。
【請求項３５】
最新の攻撃パターンを示すパターン情報に基づいた攻撃パケットを発生する攻撃発生手段をさらに具備し、
前記送信手段は、前記攻撃パケットを前記通信相手装置へ送信し、
前記受信手段は、前記通信相手装置が備えるセキュリティ対策システムによって検知された、前記攻撃パケットに基づいた攻撃を示す攻撃検知情報を前記通信相手装置から受信し、
前記検証手段は、前記攻撃検知情報および前記パターン情報に基づいて、前記通信相手装置の通信上の安全性を検証し、前記通信相手装置の通信上の安全性を確認した場合に、前記安全性証明情報に対して前記署名情報を付加して、前記通信相手装置へ送信する
ことを特徴とする請求項３１に記載の安全性保証装置。
【請求項３６】
セキュリティ対策の種別を示すセキュリティ対策情報と、前記セキュリティ対策情報の有効性を示す情報とが関連付けられた失効情報を記憶する記憶手段をさらに具備し、
前記証明情報生成手段はさらに、前記通知情報に含まれる前記通信相手装置のセキュリティ対策情報を暗号化して前記安全性証明情報に付加し、
前記有効性判断手段はさらに、前記通信元装置から前記安全性証明情報の有効性の判断を要求された場合に、前記安全性証明情報中の前記セキュリティ対策情報を復号化し、復号化後の前記セキュリティ対策情報と前記失効情報とに基づいて前記安全性証明情報の有効性を判断する
ことを特徴とする請求項３２に記載の安全性保証装置。
【請求項３７】
前記安全性保証装置はさらに、セキュリティ対策の種別を示すセキュリティ対策情報と、前記種別を識別する識別情報と、前記種別の有効性を示す情報とが関連付けられた失効情報を記憶する記憶手段をさらに具備し、
前記証明情報生成手段はさらに、前記通知情報に含まれる前記通信相手装置のセキュリティ対策情報に対応した前記識別情報を前記安全性証明情報に付加し、
前記有効性判断手段はさらに、前記通信元装置から前記安全性証明情報の有効性の判断を要求された場合に、前記安全性証明情報中の前記識別情報と前記失効情報とに基づいて前記安全性証明情報の有効性を判断する
ことを特徴とする請求項３２に記載の安全性保証装置。
【請求項３８】
前記失効情報において、同一の前記種別に対して、異なる複数の前記識別情報が関連付けられていることを特徴とする請求項３７に記載の安全性保証装置。
【請求項３９】
前記失効情報において、前記種別と、前記種別を識別する識別番号とが関連付けられており、前記識別番号の付与の際には、失効した前記種別に付与された前記識別番号以下の全識別番号と関連付けられている前記種別が失効している状態となるように、前記識別番号が付与されることを特徴とする請求項３７に記載の安全性保証装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信相手の安全レベルを保証することを図った通信システムおよび安全性保証装置に関する。
【背景技術】
【０００２】
ＰＫＩ（Public Key Infrastructure：公開鍵基盤）は、既存のインターネットにおける通信相手を認証するための基盤技術であり（例えば非特許文献１参照）、社会的に信頼されているＣＡ（Certificate Authority：認証局）が、公開鍵と秘密鍵のペアを作成したホストの公開鍵に対して「確かに該当ホストが公開鍵を作成した」ことを保証する技術である。ＰＫＩにおいては、通信相手（ここではサーバと呼ぶ）が生成した公開鍵と秘密鍵のペアのうち公開鍵に対して、社会的に信頼されているＣＡが、自身の秘密鍵を使ってデジタル署名（証明書の発行）を施した公開鍵証明書（ＰＫＣ：Public Key Certificate）を発行している。通信の受け側（ここではクライアントと呼ぶ）は、通信相手から送られてきたＰＫＣを確認するために、ＣＡの公開鍵を用いてＰＫＣのデジタル署名を検証し、通信相手の本人性（識別性）を認証している。
【０００３】
ＣＡは、公開鍵と秘密鍵のペアを作成したサーバから公開鍵を受け取り、サーバの身元をオフラインで確認した後に、その公開鍵を含む証明書を発行する。ここで発行とは、サーバの公開鍵とその付随情報を含めた情報の全体に、ＣＡ自身の秘密鍵でデジタル署名を施す処理である。代表的な証明書として、Ｘ．５０９証明書がある（例えば非特許文献２〜４参照）。
【０００４】
この証明書には、本人性の証明用のＰＫＣと、ＰＫＣにリンク付けされた属性証明用の属性証明書（ＡＣ：Attribute Certificate）とがある（図２２参照）。ＰＫＣやＡＣの拡張領域には、公開鍵所有者に付随する情報や証明書の利用目的などの属性情報を付加することが可能である。ただし、頻繁に属性が更新される場合には、ＰＫＣの更新コストが問題になるため、ＡＣを利用することになる。ＰＫＣは、信頼されるＣＡに発行・管理されるが、ＡＣはローカルな属性認証局（ＡＡ：Attribute Authority）で発行・管理してもよい。
【０００５】
図２３は、ＣＡおよびＡＡによるＰＫＣおよびＡＣの発行・指定関係を示している。認証局（ＣＡ）１は、端末（ＥＥ）７からの要求に応じて、端末７の公開鍵証明書（ＰＫＣ）１００を発行する。属性認証局（ＡＡ）６は、端末７の公開鍵証明書１００にリンク付けされた属性証明書（ＡＣ）１０１を発行する。
【０００６】
ＰＫＣの署名が正しく、有効期限内であっても、何らかの理由により、ＰＫＣを無効化しなければならないことがある。無効化するＰＫＣは失効証明書リスト(ＣＲＬ： Certificate Revocation List)に記録される。このフォーマットを図２４に示す。
【０００７】
通信システムにおけるウィルス等の攻撃に対して、通信システムの安全性を向上させるためのシステムとして、侵入検知システム（ＩＤＳ：Intrusion Detection System）およびウィルス検知システム（ＶＤＳ：Virus Detection System）がある。ＩＤＳは、ネットワーク上を流れるパケットやホスト上のログファイルを監視して、攻撃パターンファイルと一致するパケットやログファイルを検知するとアラームを発するシステムである。図２５は、ネットワーク上のパケットを監視して、不正な行為を監視するネットワーク型ＩＤＳのモデルを示している（例えば非特許文献５参照）。
【０００８】
図において、ＩＤＳ８はネットワーク１１ａおよび１１ｂ間を流れるパケット２００を監視する。ＩＤＳ８において、パケット取得部８１は、パケット２００を取得し、攻撃検査部８２へ出力する。攻撃検査部８２は、攻撃パターンファイル３００に記録されている攻撃パターンに基づいて、取得されたパケットが攻撃によるものであるかどうか判断し、攻撃によるものであると判断した場合には、ログ３０１に記録すると共に、アラームを発する等の処理を行う。
【０００９】
一方、ＶＤＳは、ホスト上のファイルもしくはネットワーク上で送受信されるファイルの中に、コンピュータウイルスのパターンファイルと一致するコードを検知するとアラームを出力するシステムである（例えば非特許文献６参照）。一般にＶＤＳは、クライアントホストやサーバ、ネットワークＧＷ（ゲートウェイ）に設置される。
【非特許文献１】カーライル・アダムス、スティーブ・ロイド著，鈴木優一訳，「ＰＫＩ  公開鍵インフラストラクチャの概念、標準、展開」，ピアソン・エデュケーション，２０００年７月。
【非特許文献２】「Information Technology - Open Systems Interconnection - The Directory Authentication Framework.」，ITU-T Recommendation X.509，June 1997，（equivalent to ISO/IEC 9594-8，1997）
【非特許文献３】「Internet X.509 Public Key Infrastructure Certificate and CRL Profile」，IETF，RFC2459，1999.
【非特許文献４】「An Internet Attribute Certificate Profile for Authorization」，IETF，RFC3281，2002
【非特許文献５】武田圭史、磯崎宏，「ネットワーク侵入検知」，ソフトバンク  パブリッシング，２０００年６月
【非特許文献６】アトミックドロップ，「まるごと図解  最新 コンピュータウイルスがわかる」，技術評論社，２０００年１０月
【発明の開示】
【発明が解決しようとする課題】
【００１０】
しかし、従来の通信システムにおいては、通信相手の本人性を認証することはできるものの、その通信の安全性レベルを保証するものではなかった。従って、通信相手のサーバが悪意のサーバや、セキュリティ対策を図っていないサーバであった場合、クライアント側が攻撃されることもあるという問題点があった。
【００１１】
本発明は、上述した問題点に鑑みてなされたものであって、通信相手がセキュリティ対策を施していることを保証することができる通信システムおよび安全性保証装置を提供することを目的とする。
【課題を解決するための手段】
【００１２】
本発明は、上記の課題を解決するためになされたもので、通信元装置と、該通信元装置と通信を行う通信相手装置と、前記通信相手装置の通信上の安全性を保証する安全性保証装置とを具備する通信システムであって、前記通信相手装置は、自身の通信上の安全性を通知するための通知情報を前記安全性保証装置へ送信し、前記安全性保証装置は、前記通知情報を受信し、該通知情報に基づいて前記通信相手装置の通信上の安全性を検証し、該通信上の安全性を確認した場合に、該通信上の安全性を証明する安全性証明情報を生成して前記通信相手装置へ送信し、前記通信相手装置は、前記安全性証明情報を受信し、前記通信元装置からの接続要求に応じて前記安全性証明情報を前記通信元装置へ送信し、前記通信元装置は、前記通信相手装置に対する接続要求の後、前記通信相手装置から前記安全性証明情報を受信し、該安全性証明情報に基づいて前記通信相手装置の通信上の安全性を検証することを特徴とする通信システムである。
【００１３】
本発明は、通信元装置と、該通信元装置と通信を行う通信相手装置と、前記通信相手装置の通信上の安全性を保証する安全性保証装置とを具備する通信システムであって、前記通信相手装置は、自身の通信上の安全性を証明する安全性証明情報を前記安全性保証装置へ送信し、前記安全性保証装置は、前記安全性証明情報を受信し、該安全性証明情報に対して署名情報を付加して、前記安全性証明情報を前記通信相手装置へ送信し、前記通信相手装置は、前記安全性証明情報を受信し、前記通信元装置からの接続要求に応じて、前記署名情報の付加された前記安全性証明情報を前記通信元装置へ送信し、前記通信元装置は、前記通信相手装置に対する接続要求の後、前記通信相手装置から前記安全性証明情報を受信し、該安全性証明情報、および該安全性証明情報に付加された前記署名情報に基づいて前記通信相手装置の通信上の安全性を検証することを特徴とする通信システムである。
【００１４】
本発明は、通信元装置と、該通信元装置からの接続要求に応じて、該通信元装置と通信を行う通信相手装置と、前記通信相手装置の通信上の安全性を保証する安全性保証装置とを具備する通信システムにおける安全性保証装置であって、前記通信相手装置によって送信された、該通信相手装置の通信上の安全性を通知する通知情報を受信する受信手段と、前記通知情報に基づいて前記通信相手装置の通信上の安全性を検証する検証手段と、該検証手段によって前記通信相手装置の通信上の安全性が確認された場合に、該通信上の安全性を証明する安全性証明情報を生成する証明情報生成手段と、該安全性証明情報を前記通信相手装置へ送信する送信手段とを具備することを特徴とする安全性保証装置である。
【００１５】
本発明は、通信元装置と、該通信元装置からの接続要求に応じて、該通信元装置と通信を行う通信相手装置と、前記通信相手装置の通信上の安全性を保証する安全性保証装置とを具備する通信システムにおける安全性保証装置であって、前記通信相手装置によって送信された、該通信相手装置の通信上の安全性を通知する安全性証明情報を受信する受信手段と、前記安全性証明情報に対して署名情報を付加する署名情報付加手段と、該署名情報が付加された前記安全性証明情報を前記通信相手装置へ送信する送信手段とを具備することを特徴とする安全性保証装置である。
【発明の効果】
【００１６】
本発明によれば、安全性保証装置が通信相手装置の通信上の安全性を証明するようにしたので、通信相手がセキュリティ対策を施していることを保証することができるという効果が得られる。
【発明を実施するための最良の形態】
【００１７】
以下、図面を参照し、本発明を実施するための最良の形態について説明する。図１は、本発明の一実施形態による通信システムの構成を示すブロック図である。この通信システムは、サーバ・クライアント通信におけるサーバの本人性の認証を行うと共に、その通信の安全性のレベル（セキュリティレベル）を保証するシステムである。図において、認証局（ＣＡ）１は既存の認証局であり、サーバ３からのＰＫＣ（公開鍵証明書）の発行要求に応じて、サーバ３の公開鍵についてのＰＫＣ１０２（識別性情報）を発行する。セキュリティ保証局（ＳＣＡ）２（安全性保証装置）は、サーバ３のセキュリティレベルを保証するためのＡＣ（属性証明書）１０５を発行する。このセキュリティ保証局２は、既存の認証局１によって認証され、自身の公開鍵についてのＰＫＣを発行されており、社会的に信頼されている第三者的な立場の機関とする。
【００１８】
サーバ３（通信相手装置）は本人性および安全性の検証の対象となるサーバであり、セキュリティ対策システムの一種であるＩＤＳ（侵入検知システム）３２およびＶＤＳ（ウィルス検知システム）３３を備えている。クライアント４（通信元装置）はサーバ３に接続してサービスを受けようとしている端末装置である。このクライアント４は、サーバ３に対して発行されたＰＫＣ１０２およびＡＣ１０５に基づいて、サーバ３の本人性（識別性）およびセキュリティレベル（通信上の安全性）の検証を行う署名検証部４１を備えている。なお、認証局１、セキュリティ保証局２、サーバ３、およびクライアント４は図示せぬインターネットを介して相互に接続されている。
【００１９】
図２は、セキュリティ保証局２の構成を示すブロック図である。以下、図中の各構成について説明する。通信部２１は、インターネット１０を介してサーバ３、クライアント４、およびＩＤＳ・ＶＤＳベンダ５等の他の通信装置と情報の送受信を行う。ＩＤＳ・ＶＤＳベンダからの情報取得部２２は、通信部２１を介してＩＤＳ・ＶＤＳベンダ５から最新のＩＤＳ／ＶＤＳのパターンファイルを取得し、記憶部２８に格納する。ＩＤＳ／ＶＤＳのパターンファイルには、ＩＤＳおよびＶＤＳが検知すべき攻撃やウィルスのパターンが予め記録されている。
【００２０】
サーバとの通信制御部２３はサーバ３との通信を制御する。クライアントとの通信制御部２４はクライアント４との通信を制御する。サーバ認証部２５はサーバ３の本人性およびセキュリティレベルの認証を行う。サーバへのＩＤＳ・ＶＤＳパターンファイル適用部２６は、サーバ３に仕掛ける擬似攻撃を生成するが、詳細については後述する。属性証明書発行部２７は、サーバ認証部２５によってサーバ３の本人性およびセキュリティレベルが確認された場合に、属性証明書（ＡＣ）を発行する。記憶部２８は、サーバ３に対するＡＣの発行に必要な情報や、自身の公開鍵・秘密鍵に関する情報、発行したＡＣ等を記憶する。
【００２１】
図３は、サーバ３の構成を示すブロック図である。以下、図中の各構成について説明する。通信部３１は、インターネット１０を介して認証局１、セキュリティ保証局２、およびクライアント４等の他の通信装置と情報の送受信を行う。クライアント通信制御部３４はクライアント４との通信を制御する。クライアントからのセッション受付部３５は、クライアント４からの接続要求があった場合に、クライアント４との通信にセッションを設定し、そのセッションを管理する。
【００２２】
ＩＤＳ／ＶＤＳの起動監視部３６はｐｓコマンドやｌｓコマンドを用いてＩＤＳ３２およびＶＤＳ３３の起動を確認し、それらの起動状態に関する情報を取得するが、詳細については後述する。ＳＣＡとの通信制御部３７はセキュリティ保証局２との通信を制御する。記憶部３８は、自身の公開鍵・秘密鍵に関する情報や、認証局１によって発行されたＰＫＣ、セキュリティ保証局２によって発行されたＡＣ、ＩＤＳ／ＶＤＳの運用に関する情報（ログ、パターンファイル）等の情報を記憶する。
【００２３】
次に、本実施形態による通信システムの動作について説明する。前提として、セキュリティ保証局２は自身の公開鍵と秘密鍵のペアを作成し、認証局１からＰＫＣを発行されているものとする。また、セキュリティ保証局２はＩＤＳ・ＶＤＳベンダ５からＩＤＳ／ＶＤＳの最新のパターンファイルを取得しているものとする。サーバ３は自身の公開鍵と秘密鍵のペアを生成し（ステップＳ１）、生成した公開鍵の正当性を保証するデジタル署名を依頼するためのＰＫＣ発行要求情報を生成し、認証局１へ送信する（ステップＳ２）。このＰＫＣ発行要求情報には、サーバ３の公開鍵が含まれている。
【００２４】
認証局１はＰＫＣ発行要求情報を受信し、サーバ３の身元の確認後、ＰＫＣ発行要求情報に付加されたサーバ３の公開鍵を含むサーバ３の情報に対して、自身の秘密鍵によりデジタル署名を施した署名情報を含むＰＫＣ１０２を生成し、サーバ３へ送信する（ステップＳ３）。このＰＫＣ１０２はサーバ３の通信部３１によって受信され、ＩＤＳ３２を介して記憶部３８に格納される。一方、セキュリティ保証局２においてサーバとの通信制御部２３は記憶部２８から最新のＩＤＳ／ＶＤＳのパターンファイルを読み出し、通信部２１を介して、ＩＤＳ／ＶＤＳパターンファイル１０３としてサーバ３へ送信する（ステップＳ４）。
【００２５】
サーバ３において通信部３１はセキュリティ保証局２からＩＤＳ／ＶＤＳパターンファイル１０３を受信し、ＩＤＳ３２へ出力する。ＩＤＳ３２はこのＩＤＳ／ＶＤＳパターンファイル１０３を記憶部３８に格納する。また、ＳＣＡとの通信制御部３７は、認証局１によって発行されたＰＫＣ１０２にリンク付けされるＡＣの発行を要求するためのＡＣ発行要求情報を生成し、ＩＤＳ３２および通信部３１を介してセキュリティ保証局２へ送信する（ステップＳ５）。このＡＣ発行要求情報には、サーバ３のＰＫＣ１０２（識別性証明情報）と、ＡＣの発行に必要な情報１０４（通知情報）とが含まれる。ＰＫＣ１０２は、サーバ３がセキュリティ保証局２に対して自身の身元を証明するための情報であり、ＡＣの発行に必要な情報１０４は、自身のＩＤＳ３２およびＶＤＳ３３に関する情報等、自身のセキュリティレベルをセキュリティ保証局２に通知するための情報である。ＡＣの発行に必要な情報１０４はＰＫＣ１０２の拡張領域に格納されていてもよい。
【００２６】
セキュリティ保証局２はサーバ３からＡＣ発行要求情報を受信し、ＰＫＣ１０２に基づいてサーバ３を認証すると共に、ＡＣの発行に必要な情報１０４に基づいてサーバ３のセキュリティレベルの認証を行い、両方の認証に成功した場合に、ＰＫＣ１０２に基づいてＡＣ１０５を生成し、サーバ３へ送信する（ステップＳ６）。以下、ステップＳ６におけるセキュリティ保証局２の動作を詳述する。
【００２７】
サーバとの通信制御部２３は、通信部２１を介してサーバ３からＡＣ発行要求情報を受信し、サーバ認証部２５へ出力する。サーバ認証部２５は、ＡＣ発行要求情報に付加されたＰＫＣ１０２に基づいて、サーバ３の身元を検証する。具体的には、サーバ認証部２５は、ＰＫＣ１０２に付加されている、認証局１の秘密鍵によって暗号化されたデジタル署名を認証局１の公開鍵で復号化し、デジタル署名の復号化によって得られた公開鍵等のデータと、ＰＫＣ１０２に付加されている公開鍵等の非暗号化データとを比較し、両者が一致した場合に、サーバ３の身元の認証に成功したとする。
【００２８】
また、サーバ認証部２５は、ＡＣ発行要求情報に付加されたＡＣの発行に必要な情報１０４に基づいて、サーバ３のセキュリティレベルを検証する。サーバ認証部２５は、ＡＣの発行に必要な情報１０４に含まれる情報から、サーバ３がセキュリティ対策を施しているかどうか知ることができ、さらに、後述する各手法により、サーバ３のセキュリティレベルをより正しく知ることができる。サーバ３の身元の認証およびセキュリティレベルの認証に成功した場合、サーバ認証部２５は、属性証明書発行部２７に対してＡＣの発行を指示する。指示を受けた属性証明書発行部２７は、ＰＫＣ１０２に基づいてＡＣを生成し、記憶部２８に格納する。このＡＣには、セキュリティ保証局２の秘密鍵によるデジタル書名が付与されており、また、拡張領域にはサーバ３のセキュリティレベルを証明する情報（安全性証明情報）が格納されている。属性証明書発行部２７は、サーバ認証部２５を介してＡＣをサーバとの通信制御部２３へ出力し、サーバとの通信制御部２３は、通信部２１を介して、このＡＣをＡＣ１０５としてサーバ３へ送信する（ステップＳ６）。
【００２９】
続いて、クライアント４は、サーバ３との通信を開始するために、サーバ３に対する接続要求と、ＰＫＣ１０２およびＡＣ１０５の受信要求とを示す接続要求情報をサーバ３へ送信する（ステップＳ７）。サーバ３において通信部３１は接続要求情報を受信し、ＩＤＳ３２を介してクライアントからのセッション受付部３５へ出力する。クライアントからのセッション受付部３５は、接続要求情報に基づいてクライアント４とのセッションを生成すると共に、ＰＫＣ１０２およびＡＣ１０５の送信をクライアント制御部３４に指示する。指示を受けたクライアント制御部３４は記憶部３８からＰＫＣ１０２およびＡＣ１０５を読み出し、ＩＤＳ３２を介して通信部３１へ出力する。通信部３１はＰＫＣ１０２およびＡＣ１０５をクライアント４へ送信する（ステップＳ８）。
【００３０】
クライアント４はサーバ３からＰＫＣ１０２およびＡＣ１０５を受信し、自身が認証局１およびセキュリティ保証局２の公開鍵を所持している場合には、ＰＫＣ１０２およびＡＣ１０５のデジタル署名を検証する（ステップＳ９）。すなわち、クライアント４の署名検証部４１は、ＰＫＣ１０２に付加されている、認証局１の秘密鍵によって暗号化されたデジタル署名を認証局１の公開鍵で復号化し、デジタル署名の復号化によって得られた公開鍵等のデータと、ＰＫＣ１０２に付加されている公開鍵等の非暗号化データとを比較し、両者が一致した場合に、サーバ３の身元の認証に成功したとする。
【００３１】
また、署名検証部４１は、ＡＣ１０５に付加されている、セキュリティ保証局２の秘密鍵によって暗号化されたデジタル署名をセキュリティ保証局２の公開鍵で復号化し、デジタル署名の復号化によって得られた公開鍵等のデータと、ＡＣ１０５に付加されている公開鍵等の非暗号化データとを比較し、両者が一致した場合に、サーバ３のセキュリティレベルの認証に成功したとする。
【００３２】
一方、クライアント４が認証局１およびセキュリティ保証局２の少なくとも一方の公開鍵を予め所持していない場合には、以下のようになる。クライアント４が認証局１の公開鍵を予め所持していない場合には、クライアント４は、認証局１に対してＰＫＣを要求する（ステップＳ１０ａ）。ＰＫＣを要求された認証局１は、自身の公開鍵についてのＰＫＣ１０６をクライアント４へ送信する（ステップＳ１１ａ）。クライアント４はＰＫＣ１０６を受信し、署名検証部４１は、ＰＫＣ１０６を用いてＰＫＣ１０２のデジタル署名を検証する。
【００３３】
また、クライアント４がセキュリティ保証局２の公開鍵を予め所持していない場合には、クライアント４は、セキュリティ保証局２に対してＰＫＣを要求する（ステップＳ１０ｂ）。ＰＫＣを要求されたセキュリティ保証局２は、自身の公開鍵についてのＰＫＣ１０７をクライアント４へ送信する（ステップＳ１１ｂ）。クライアント４はＰＫＣ１０７を受信し、署名検証部４１は、ＰＫＣ１０７を用いてＡＣ１０５のデジタル署名を検証する。
【００３４】
上記の検証の結果、サーバ３のＰＫＣ１０２およびＡＣ１０５のデジタル署名の有効性が確認できた場合、サーバ３およびクライアント４は以後の通信を開始する。また、サーバ３のＩＤＳ３２およびＶＤＳ３３は、サーバ３側の通信を監視する（ステップＳ１２）。ＰＫＣ１０２およびＡＣ１０５のデジタル署名の有効性が確認できた場合には、クライアント４は、ＡＣ１０５に関する概要情報（図４（ａ）参照）や詳細情報（図４（ｂ）参照）を図示せぬ表示部に表示する。これにより、ユーザはサーバ３のセキュリティレベルを視覚的に確認することができる。また、図４（ａ）に示されるように、その表示に基づいて、ユーザに対して通信の開始の可否を選択させるようにしてもよい。
【００３５】
次に、セキュリティ保証局２によるサーバ３のセキュリティレベルの認証について説明する。セキュリティ保証局２によって発行されるＡＣ１０５の拡張フィールドには、セキュリティを保証する以下の情報のうちいくつかが付加される。ただし、これは、サーバ３が厳密な情報を提供する場合である。
・証明書の発行先情報（サーバ３を特定する情報）
・証明書の発行者情報（セキュリティ保証局２を特定する情報）
・証明書の発行日（証明書が生成された時を特定する情報）
・証明書の有効期限
・証明書を作成するためのアルゴリズムに関する諸情報
・ＩＤＳやＶＤＳにより通信を監視している事実
・ＩＤＳやＶＤＳに関するツール名もしくはツールＩＤ（ＩＤＳやＶＤＳを特定する情報）
・ＩＤＳやＶＤＳに関するバージョン番号（ＩＤＳやＶＤＳを特定する情報）
・ＩＤＳやＶＤＳの最新適用パターンファイルＩＤ（ＩＤＳやＶＤＳを特定する情報）
・ＩＤＳやＶＤＳの最新適用パターンファイル発行日（ＩＤＳやＶＤＳを特定する情報）
・監視ポリシ
【００３６】
サーバ３において複数のセキュリティツールが適用されている場合には、各セキュリティツールに関しての複数の情報が記載される。また、ＩＤＳやＶＤＳで、通信をどのように監視するのかといったポリシ自体もしくはポリシＩＤが記載される。ここでポリシとは、ＩＰスキャン攻撃は検知するが、ポートスキャン攻撃は検知しないといったパターンファイルの利用方法である。
【００３７】
上記のような厳密な情報は、場合によってはセキュリティ情報の漏洩に繋がる場合もある。例えば、脆弱性を持つＩＤＳやＶＤＳを利用している場合や、パターンファイルの適用の遅れ等は、監視システムからの回避情報を侵入者に知らせることにもなる。よって、下記の情報のみがＡＣ１０５の拡張フィールドに格納され、セキュリティ保証局２が保証するレベルのみをクライアント４に通知してもよい。
・証明書の発行先情報
・証明書の発行者情報
・証明書の発行日
・証明書の有効期限
・証明書を作成するためのアルゴリズムに関する諸情報
・ＩＤＳやＶＤＳにより通信を監視している事実
【００３８】
上記の情報は、セキュリティ保証局２が独自に決定するか、またはサーバ３からセキュリティ保証局２へ送信されるＡＣの発行に必要な情報１０４に基づいてセキュリティ保証局２が生成する。例えば、証明書の発行先情報は、サーバ３から取得したＰＫＣ１０２に基づいてセキュリティ保証局２が生成する。また、証明書の発行者情報、証明書の発行日、証明書の有効期限、証明書を作成するためのアルゴリズムに関する諸情報もセキュリティ保証局２が決定する。その他、ＩＤＳやＶＤＳにより通信を監視している事実、ＩＤＳやＶＤＳに関するツール名もしくはツールＩＤ等の情報は、サーバ３から取得したＡＣの発行に必要な情報１０４に基づいて、セキュリティ保証局２が生成する。
【００３９】
セキュリティ保証局２は、サーバ３の本人性の認証に成功した場合であって、ＡＣの発行に最低限必要な情報として、ＩＤＳやＶＤＳにより通信を監視している事実を示す情報がＡＣの発行に必要な情報１０４に格納されていた場合に、その情報に基づいて、サーバ３がセキュリティ対策を行っていることを信用し、ＡＣ１０５を生成してサーバ３へ送信してもよいが、サーバ３が悪意のサーバである可能性もあるため、サーバ３のセキュリティレベルをより確実に保証する手法が必要である。以下、このための手法について説明する。
【００４０】
（１）インターネットサービスプロバイダ（ＩＳＰ）等によるサーバシステムの管理
サーバ３や、サーバ３の処理を代行する後述の外部装置をＩＳＰやセキュリティ保証局２等の施設内で管理している環境では、サーバ３におけるＩＤＳやＶＤＳの動作状況をＩＳＰやセキュリティ保証局２の運用者が直接確認する。
【００４１】
（２）サーバシステム自体の耐タンパ性の利用
ＩＳＰやセキュリティ保証局２が、サーバ３の処理を代行する後述するような外部装置を提供する場合に、その装置の耐タンパ性（不正アクセス・不正改竄防止機能）を担保にする。例えば、サーバ３の処理を代行する外部装置には、その装置が開封されただけで、その装置の動作を規定するソフトウェアが記録されているメモリおよびディスクや、その装置の動作を実現する回路自体等が物理的に壊れて、使用不能となってしまう仕組みを設ける。これにより、外部装置の内部構成を保護し、偽造を防ぐことができる。
【００４２】
また、ＳＳＨ通信による両方向の認証を利用して、サーバ３の処理を代行する外部装置またはサーバ３自体に、ＩＳＰやセキュリティ保証局２からしかＩＤＳやＶＤＳを遠隔操作することができない仕組みを設ける。以下、この場合について詳述する。ＳＳＨによる両方向の認証には、公開鍵暗号認証方式およびパスワード認証方式の２種類がある。以下、一般に用いられている「発信元」「着信元」モデルについて説明する。
【００４３】
公開鍵暗号認証方式においては、発信元は自身の持つ秘密鍵によって署名した電子署名データを着信先に送信する。着信先は、発信元の公開鍵により電子署名データを復号化し、その電子署名の正当性を検証する。検証には、既存の認証局が発行したＰＫＣを利用する。セキュリティ保証局２とサーバ３との間の両方向でお互いにＰＫＣを交換し合うことにより、お互いを認証し合うことができる。一方、パスワード認証方式においては、予め発信元と着信先の両者で取り決めておいたパスワードを送受信することにより、認証を行う。これは、広く一般で利用されている方式であるが、ＳＳＨ通信の場合、このパスワードは暗号によって保護されて送受信される。この場合、セキュリティ保証局２とサーバ３との間で予めパスワードを取り決めておく。なお、通信セッションの開始はセキュリティ保証局２およびサーバ３のどちらからでもよい。
【００４４】
上記の認証の後、セキュリティ保証局２とサーバ３は暗号通信（例えば秘密鍵暗号方式）を行う。この暗号通信において、セキュリティ保証局２は、サーバ３の各部を制御し、操作するための操作情報をサーバ３へ送信してサーバ３を遠隔操作する。サーバ３は、操作情報に基づいて、ＩＤＳ３２およびＶＤＳ３３に関する情報を生成し、セキュリティ保証局２へ送信する。セキュリティ保証局２は、その情報を受信し、ＡＣの発行に必要な情報１０４の代わりに用いて、サーバ３のセキュリティレベルの検証を行う。
【００４５】
また、上記の動作は、セキュリティ保証局２がサーバ３を遠隔操作するのではなく、サーバ３が主体的に動作することにより行ってもよい。すなわち、サーバ３はセキュリティ保証局２との両方向の認証後、ＩＤＳ３２およびＶＤＳ３３に関する情報を生成し、セキュリティ保証局２へ送信する。セキュリティ保証局２は、その情報を受信し、ＡＣの発行に必要な情報１０４の代わりに用いて、サーバ３のセキュリティレベルの検証を行う。
【００４６】
（３）サーバ側での監視処理の起動確認
サーバ３上にＩＤＳ３２やＶＤＳ３３の状態を確認する専用の機能を予め用意する。Ｌｉｎｕｘ  ＯＳの場合には、「ｐｓ」コマンドにより、起動プロセスの情報を得る機能がある。サーバ３上でｐｓコマンドを実行することにより得られた情報の中から、ＩＤＳプロセス（またはＶＤＳプロセス）の名前、ＩＤＳプロセス（またはＶＤＳプロセス）のサイズを取得して、それらが正しい情報であれば（サーバ３がセキュリティ保証局２へ通知した情報と同じであれば）、起動していると判断する。具体的なコマンドは以下の通りである。
> ps -ef | grep プロセス名
【００４７】
また、適用されているパターンファイルが最新のものであることを確認するために、サーバ３上で「ｌｓ」 コマンドを実行することにより得られた情報の中から、パターンファイルの名前、パターンファイルのサイズ、パターンファイルの日付（更新日）を取得して、最新のパターンファイルを適用したことが分かる情報を得る。具体的なコマンドは以下の通りである。
> ls -l ディレクトリ名/ファイル名
【００４８】
サーバ３は、上記の２つのコマンドを実行することにより取得した、ＩＤＳ３２またはＶＤＳ３３の状態を示す状態情報をまとめてセキュリティ保証局２へ送信する。ただし、このとき悪意のサーバは、情報を偽装する恐れがある。これを防止するために、上記の２つの情報収集処理と、これをセキュリティ保証局２に送信する処理を一つのプログラムとして作成しておき、このプログラムに対してソフトウェアの難読化を実施して、実行モジュールの改竄を防止する。
【００４９】
難読化とは、整然と書かれているプログラムの構造を変形させることにより、実行結果は変わらないものの、その解析を困難にする技術である。具体的には、
・実行に影響を与えない不要なコードを追加する。
・命令コードを別の等価なコードに置き換える。
・一つの計算を複数の計算に分割する。
・一つの機能を持ったモジュール（関数、サブルーチン）を複数のモジュールに分割する。
・同一の処理を行うモジュールを複数用意して冗長化する。
等の操作をそのプログラムに対して行う。難読化のタイミングとしては二種類あり、一つは、ソースコードを難読化してからコンパイルして実行コードを得るというものであり、もう一つは、ソースコードをコンパイルしてから難読化して実行コードを得るというものである。
【００５０】
上記の起動確認を行う場合、サーバ３のＩＤＳ／ＶＤＳの起動監視部３６は、ｐｓコマンドまたはｌｓコマンドに相当する処理を実行し、ＩＤＳ３２またはＶＤＳ３３（あるいは両方）について、上記の起動プロセスまたはパターンファイルについての状態情報を生成し、ＩＤＳ３２を介して通信部３１へ出力する。通信部３１は状態情報をセキュリティ保証局２へ送信する。
【００５１】
セキュリティ保証局２の通信部２１は状態情報を受信し、サーバとの通信制御部２３を介してサーバ認証部２５へ出力する。サーバ認証部２５は、サーバ３のセキュリティレベルを以下のように認証する。サーバ認証部２５は、サーバ３から受信されたＡＣの発行に必要な情報１０４と状態情報とを比較し、状態情報が示すＩＤＳプロセスの名前、ＩＤＳプロセスのサイズ、パターンファイルの名前、パターンファイルのサイズ、およびパターンファイルの日付が、ＡＣの発行に必要な情報１０４に含まれるそれらの内容と一致するかどうか検証する。
【００５２】
状態情報の内容がＡＣの発行に必要な情報１０４に含まれる情報の内容と一致した場合、サーバ認証部２５はサーバ３のセキュリティレベルを確認することができたとし、認証を終了する。これにより、セキュリティ保証局２は、ＡＣの発行に必要な情報１０４としてサーバ３から通知された情報が、改竄できない実行モジュールに基づいて得た状態情報の内容と一致する正しい情報であることを知ることができ、サーバ３のセキュリティレベルをより確実に確認および保証することができる。なお、上記の場合、サーバ３がセキュリティ保証局２へ送信するＡＣの発行に必要な情報１０４には、ＩＤＳ３２またはＶＤＳ３３の状態情報が含まれている必要がある。
【００５３】
（３）パターンファイルの適用の外部からの確認
セキュリティ保証局２が、サーバ３に対して擬似攻撃を仕掛け、サーバ３のＩＤＳ３２またはＶＤＳ３３によって出力されたログを取得し、そのログに基づいて、サーバ３が最新のパターンファイルを適用しているかどうか確認する。この場合、サーバへのＩＤＳ・ＶＤＳパターンファイル適用部２６は記憶部２８から最新のパターンファイル（パターン情報）を読み出し、更新された攻撃パターン（シグネチャ）を認識する。更新された攻撃パターンの認識において、サーバへのＩＤＳ・ＶＤＳパターンファイル適用部２６は記憶部２８から最新のパターンファイルおよびその一つ前のバージョンのパターンファイルを読み出し、両者の内容を比較し、最新のパターンファイルのみに含まれるパターンを、更新された攻撃パターンとして認識してもよい。
【００５４】
続いて、サーバへのＩＤＳ・ＶＤＳパターンファイル適用部２６は、更新された攻撃パターンに基づいた攻撃パケットを連続的に生成し、サーバ認証部２５を介してサーバとの通信制御部２３へ出力する。サーバとの通信制御部２３は攻撃パケットを連続的にサーバ３へ送信する。サーバ３の通信部３１は攻撃パケットを受信し、ＩＤＳ３２へ出力する。ＩＤＳ３２は記憶部３８から最新のパターンファイルを読み出し、そのパターンファイルに基づいてパケットを監視し、最新の攻撃パターンと一致するパケットを検知した場合には、その攻撃パターン名（シグネチャ名）、送信元ＩＰ、時刻情報等をログ（攻撃検知情報）に記録する。
【００５５】
ＩＤＳ３２は所定のタイミングでログを読み出し、通信部３１へ出力する。通信部３１はログをセキュリティ保証局２へ送信する。セキュリティ保証局２の通信部２１はログを受信し、サーバとの通信制御部２３を介してサーバ認証部２５へ出力する。サーバ認証部２５は、更新された攻撃パターンがログに記録されているかどうか検証し、記録されていた場合には、サーバ３のセキュリティレベルを確認することができたとし、認証を終了する。これにより、セキュリティ保証局２は、サーバ３が最新のパターンファイルに基づいたセキュリティ対策を行っているかどうか確認することができ、サーバ３のセキュリティレベルをより確実に確認および保証することができる。
【００５６】
なお、セキュリティ保証局２が、ウィルスに関しての最新のパターンファイルに基づいて、ウィルスに感染した攻撃パケットを生成し、サーバ３へ送信してもよい。この場合、サーバ３においては、ＶＤＳ３３が、最新のパターンファイルに基づいて、ウィルスによるパケットを検出し、ログに記録する。セキュリティ保証局２は、上記と同様にしてこのログを取得し、最新のパターンファイルおよびログに基づいて、サーバ３のセキュリティレベルを認証する。
【００５７】
次に、ＰＫＣおよびＡＣの発行処理の他の形態について説明する。既存の認証局１がセキュリティ保証局２の役割を担うこともでき、その場合には、ＰＫＣとＡＣとの両方を認証局１が発行する。逆に、既存の認証局１の役割をセキュリティ保証局２が代行することもでき、その場合には、ＰＫＣとＡＣとの両方をセキュリティ保証局２が発行する。また、既存の認証局１はＰＫＣを発行し、ＩＤＳ／ＶＤＳベンダーがＡＣを発行する場合も考えられる。
【００５８】
次に、ＩＤＳやＶＤＳとそのパターンファイルの管理および更新の形態ついて説明する。ＩＤＳやＶＤＳの選定からパターンファイルの適用等の運用・管理に至るまで、サーバ管理者が独自に行ってもよいし、ＩＤＳやＶＤＳの選定はサーバ管理者が行い、そのパターンファイルの適用に関しては、セキュリティ保証局２もしくはＩＤＳやＶＤＳを提供するベンダーが代行してもよい。あるいは、ＩＤＳやＶＤＳの選定からパターンファイルの適用までセキュリティ保証局２もしくは、ＩＤＳやＶＤＳを提供するベンダーが代行してもよい。この場合には、セキュリティ保証局２やベンダーは、ＩＤＳやＶＤＳが設定されたネットワーク機器（ハードウェアのゲートウェイ等）をサーバ管理者に付与して、サーバ管理者はそれを設置するのみの作業となる。
【００５９】
次に、サーバ３が行う各処理の代行について説明する。一般に、サーバを構築するときには、サーバ自体を簡易な構成にすること、余計な処理負荷を掛けないことが望まれている。そこで、
１）公開鍵と秘密鍵の生成処理
２）ＰＫＣの発行依頼と発行された証明書の管理
３）ＩＤＳ／ＶＤＳのパターンファイルの更新
４）セキュリティ保証局２に対するＡＣの発行依頼と、発行された証明書の管理
５）ＩＤＳやＶＤＳによる通信の監視
６）クライアント４へのＰＫＣとＡＣの提示
の各種処理を、外部装置が代行してもよい。図１においては、サーバ３が上記の１）から６）の全ての処理を実行するとしているが、サーバ３の処理負荷を軽減するために、プロキシ装置、ＲｏｕｔｅｒやＦｉｒｅｗａｌｌ等のネットワークゲートウェイ（Ｎ−ＧＷ）、ホームゲートウェイ（Ｈ−ＧＷ）等の装置に、１）から６）のいくつか、もしくは全ての処理を代行させてもよい。
【００６０】
次に、サーバ３がクライアント４に対してＰＫＣ１０２およびＡＣ１０５を送信する際に、この動作を行う悪意のサーバを排除する方法について説明する。サーバ３はクライアント４から接続要求を受けるとＰＫＣ１０２およびＡＣ１０５をクライアント４へ送信する。このとき、悪意のサーバはＩＤＳやＶＤＳを停止しているにも関わらず、ＡＣ１０５を送信することが考えられる。そこで、クライアント４からの接続要求を受けたサーバ３は、ｐｓコマンドやｌｓコマンドを実行して、ＩＤＳやＶＤＳが実行されていることや最新のパターンファイルの適用を確認することができた場合にのみＡＣ１０５をクライアント４へ送信する。ｐｓコマンドやｌｓコマンドによるＩＤＳやＶＤＳの起動確認処理とクライアント４へのＡＣ１０５の提示処理とを一体化ソフトウェアとして１つのプログラムにまとめておき、この一体化ソフトウェアに対して難読化を実施することにより、悪意の改竄を防止することができる。
【００６１】
次に、証明書の無効化処理について説明する。ＩＤＳやＶＤＳに関する脆弱性情報が公開された場合や、新たなパターンファイルが出た場合には、以前の状態で発行されたＡＣを無効化しなければならない。無効化のためには、図８のようなＣＲＬを用いることになる。この場合、認証局１やセキュリティ保証局２は、発行したＰＫＣやＡＣに関するＣＲＬを管理しておき、クライアント４から有効性の問い合わせがあったときに回答することになる。
【００６２】
なお、クライアント４の署名検証部４１が、サーバ３から送信されたＰＫＣ１０２およびＡＣ１０５に基づいて、サーバ３の本人性およびセキュリティレベルの認証を行う際に、ＰＫＣ１０２およびＡＣ１０５の内容に応じて、サーバ３との通信の受け入れの可否を自動的に判断するようにしてもよい。
【００６３】
上述した本実施形態においては、サーバ３がセキュリティ対策システムとしてＩＤＳ３２およびＶＤＳ３３を備えているが、Ｆｉｒｅｗａｌｌあるいは検疫システムをセキュリティ対策システムとして備えていてもよい。Ｆｉｒｅｗａｌｌは、ネットワークや端末の接続点において、許可されていないアクセスを棄却する装置であり、主に、外部ネットワークから内部ネットワークへのアクセスを制限することによって攻撃を防ぐものである。また、検疫システムは、ＯＳやアプリケーションのバージョンおよびパッチの状態を確認して最新の状態を確保するものである。
【００６４】
サーバ３がＡＣの発行に必要な情報１０４をセキュリティ保証局２へ送信する際には、自身が有するＯＳやアプリケーションのバージョン、パッチの状態、およびＰｏｒｔの設定等を確認し、ＡＣの発行に必要な情報１０４の中にこれらの情報を格納してセキュリティ保証局２へ送信するようにしてもよい。セキュリティ保証局２は、サーバ３のＯＳやアプリケーションについての上記の情報に基づいて、サーバ３のセキュリティレベルを検証してもよい。
【００６５】
本実施形態においては、既存のＰＫＩを利用して、セキュリティ保証局２がサーバ３のセキュリティレベルと共に本人性の検証を行っているが、サーバ３のセキュリティレベルの検証を行う上ではＰＫＩは必須ではない。したがって、認証局１が設けられていなくてもよく、セキュリティ保証局２とサーバ３との間でＰＫＣの送受信が行われなくてもよい。さらに、本実施形態においては、セキュリティ保証局２が、サーバ３のセキュリティレベルを証明する情報をＡＣ１０５の拡張領域に格納してサーバ３へ送信しているが、これに限定されず、サーバ３のセキュリティレベルを証明する情報を含む独立したセキュリティ証明書として送信してもよい。また、ＡＣの代わりにＰＫＩの拡張領域に上記の情報を格納してもよく、ＳＰＫＩ（例えば文献「ITU-T,"SPKI Certificate Theory",IETF,RFC2693,1999」参照）において定義される形式の証明書に上記の情報を格納してもよい。
【００６６】
次に、本実施形態の変形例について説明する。図５は、本変形例に係る通信システムの構成を示すブロック図である。図５においては認証局１の図示およびＰＫＩに基づいた本人性の認証の図示は省略されている。本変形例においても、本人性の認証を行ってもよいし、行わなくてもよい。サーバ３内に設けられた内部監査モジュール３９は、セキュリティ保証局２から外部監査（最新の攻撃パターンに基づいた擬似攻撃）を受けた場合に、ＩＤＳ３２およびＶＤＳ３３の状態あるいはＯＳ／アプリケーションのバージョン等を確認するソフトウェアまたはハードウェアである。本変形例においては、サーバ３のセキュリティレベルを証明する情報がセキュリティ証明書１０９に含まれているとする。
【００６７】
また、本変形例においては、セキュリティ証明書１０９の発行はサーバ３が行い、セキュリティ保証局２は、サーバ３が発行したセキュリティ証明書１０９に対して署名を施す。サーバ３によって発行されたサーバ３自身のセキュリティ証明書１０９は仮の状態であり、セキュリティ保証局２によって署名が施された時点で、クライアント４にとって有効な証明書となる。
【００６８】
セキュリティ保証局２は自身の公開鍵と秘密鍵のペアを作成し、既存の認証局からＰＫＣの発行を受けておく。また、クライアント４は事前にセキュリティ保証局２のＰＫＣ１０８を受信し、保持しておく（ステップＳ２１）。サーバ３はＩＤＳ３２／ＶＤＳ３３やＯＳ／アプリケーションのバージョンおよびパターンファイルの更新を行う（ステップＳ２２）。続いて、サーバ３は、上記のセキュリティ対策の更新に伴って、セキュリティ証明書への署名要求を示す情報をセキュリティ保証局２へ送信する（ステップＳ２３）。
【００６９】
この情報を受信したセキュリティ保証局２は、サーバ３におけるＩＤＳ３２およびＶＤＳ３３の起動状態やパターンファイルの状態等を確認するために、前述した動作と同様にして攻撃パケットを連続的に生成し、サーバ３へ送信する（ステップＳ２４；外部監査）。サーバ３において、通信部３１は攻撃パケットを受信し、ＩＤＳ３２へ出力する。ＩＤＳ３２は記憶部３８から最新のパターンファイルを読み出し、そのパターンファイルに基づいてパケットを監視し、最新の攻撃パターンと一致するパケットを検知した場合には、その攻撃パターン名（シグネチャ名）、送信元ＩＰ、時刻情報等を記憶部３８のログに記録する。
【００７０】
セキュリティ保証局２からの攻撃パケットがサーバ３に到着した後、内部監査モジュール３９は所定のタイミングで内部監査を行う。すなわち、内部監査モジュール３９は、ＩＤＳ３２およびＶＤＳ３３の起動状態やパターンファイルの状態を確認し、前述したＡＣの発行に必要な情報１０４と同様の情報を取得する。また、内部監査モジュール３９はＯＳやアプリケーションの状態について、不審なアプリケーションやＰｏｒｔの設定等を検査し、内部監査の結果を示す情報を生成する（ステップＳ２５）。
【００７１】
サーバ３は、内部監査モジュール３９が取得した情報に基づいて仮のセキュリティ証明書１０９を生成し、セキュリティ保証局２へ送信する。また、サーバ３は、内部監査の結果を示す情報およびログの情報を内部／外部監査結果１１０としてセキュリティ保証局２へ送信する（ステップＳ２６）。セキュリティ保証局２の通信部２１は上記のセキュリティ証明書１０９および内部／外部監査結果１１０を受信し、サーバとの通信制御部２３を介してサーバ認証部２５へ出力する。
【００７２】
サーバ認証部２５は、サーバ３に最新のセキュリティ対策が施されて、適切に運用されているかどうか検証する。すなわち、サーバ認証部２５は、擬似攻撃のパケットを生成する際に用いた最新のパターンファイルに基づいた攻撃パターンがログに記録されているかどうか検証すると共に、セキュリティ証明書１０９の形式が所定の形式に沿っているかどうか、必要な情報が格納されているかどうか等を検証する。検証の結果、最新の攻撃パターンに基づいて更新された攻撃パターンがログに記録されており、セキュリティ証明書１０９の形式等が所定の条件を満たしていた場合には、サーバ認証部２５は、サーバ３のセキュリティレベルを確認することができたとし、セキュリティ保証局２の秘密鍵を用いて署名情報を生成し、セキュリティ証明書１０９に付加する。サーバ認証部２５は、サーバとの通信制御部２３および通信部２１を介してサーバ３へこのセキュリティ証明書１０９を送信する。サーバ３は、セキュリティ保証局２によって送信されたセキュリティ証明書１０９を受信する（ステップＳ２７）。
【００７３】
なお、セキュリティ保証局２が外部監査を行わず、サーバ３からの署名要求に基づいてサーバ３へ内部監査を指示し、内部監査に基づいてサーバ３が生成したセキュリティ証明書１０９の形式的な検証を行い、セキュリティ証明書１０９に署名を施すのみとしてもよい。セキュリティ保証局２が外部監査を行い、外部監査の結果をサーバ３のセキュリティレベルの検証の材料とすることにより、サーバ３のセキュリティレベルをより確実に確認および保証することができる。
【００７４】
クライアント４は、通信の開始時点において、サーバ３に対してセキュリティ証明書１０９の提示を要求する（ステップＳ２８）。サーバ３において内部監査モジュール３９は内部監査を行い（ステップＳ２９）、ＩＤＳ３２およびＶＤＳ３３やパターンファイル等の状態がセキュリティ証明書１０９に格納された情報と同じ状態であるかどうか確認し、同じ状態であった場合には、セキュリティ保証局２の署名が付加されたセキュリティ証明書１０９をクライアント４へ送信する（ステップＳ３０）。クライアント４はセキュリティ証明書１０９を受信し、クライアント４の署名検証部４１は、セキュリティ保証局２の公開鍵を用いて、セキュリティ証明書１０９に付加されている署名の検証を行う（ステップＳ３１）。検証の結果、署名が有効であった場合には、クライアント４はサーバ３と通信を開始する。
【００７５】
次に、本実施形態の他の変形例について説明する。図６は、本変形例に係る通信システムの構成を示すブロック図である。本変形例においても、認証局１の図示は省略されている。本変形例のセキュリティ保証局２は、セキュリティ証明書の有効性の管理を行う失効証明書管理部２９を備えている。また、サーバ３において、通信モジュール４０は、前述した通信部３１や、クライアント通信制御部３４、ＳＣＡとの通信制御部３７等を含むサーバ３と外部装置との通信を制御するハードウェアまたはソフトウェアである。
【００７６】
本変形例においては、本通信システムの実装を図る上で有効な以下の３点について詳述する。
（Ａ）セキュリティ保証局２とサーバ３との間、サーバ３とクライアント４との間、およびセキュリティ保証局２とクライアント４との間において、ＴＣＰ／ＵＤＰ上で動く新たな通信プロトコル。
（Ｂ）セキュリティ証明書の発行処理および失効処理。特に、失効処理については、従来のＣＲＬを用いる処理方式に代わって、同一の内容を保証する複数のセキュリティ証明書を一斉に失効させる処理方式を示す。
（Ｃ）サーバ３の内部監査モジュール３９の耐タンパ化を図る手法。
【００７７】
まず、図６に示される本通信システムの概略動作を説明する。セキュリティ保証局２は自身の公開鍵と秘密鍵のペアを作成し、既存の認証局からＰＫＣの発行を受けておく。また、クライアント４は事前にセキュリティ保証局２のＰＫＣ１１１を受信し、保持しておく（ステップＳ４１）。サーバ３はＩＤＳ３２／ＶＤＳ３３やＯＳ／アプリケーションのバージョンおよびパターンファイルの更新を行う（ステップＳ４２）。続いて、サーバ３は、上記のセキュリティ対策の更新に伴って、セキュリティ対策システムの更新状態を示すと共に、セキュリティ証明書への署名要求を示す情報をセキュリティ保証局２へ送信する（ステップＳ４３）。
【００７８】
続いて、内部監査モジュール３９はＯＳやアプリケーションの状態について、不審なアプリケーションやＰｏｒｔの設定等を検査し、内部監査の結果を示す情報を生成する（ステップＳ４４）。通信モジュール４０は、内部監査の結果を示す情報を内部監査結果１１２としてセキュリティ保証局２へ送信する。セキュリティ保証局２は内部監査結果１１２を受信する（ステップＳ４５）。セキュリティ保証局２は、サーバ３におけるＩＤＳ３２およびＶＤＳ３３の起動状態やパターンファイルの状態等を確認するために、前述した動作と同様にして攻撃パケットを連続的に生成し、サーバ３へ送信する（ステップＳ４６；外部監査）。
【００７９】
サーバ３において、ＩＤＳ３２は、前述した動作と同様にして、最新の攻撃パターンと一致するパケットに係る情報を記憶部３８のログに記録する。通信モジュール４０はログの情報を外部監査結果１１３としてセキュリティ保証局２へ送信する。セキュリティ保証局２は外部監査結果１１３を受信する（ステップＳ４７）。内部監査と外部監査はどちらから先に行ってもよいが、本変形例においては内部監査が先に行われるものとする。
【００８０】
セキュリティ保証局２は、前述した動作と同様にして、内部監査結果１１２および外部監査結果１１３に基づいて、サーバ３に最新のセキュリティ対策が施されて、適切に運用されているかどうか検証する。すなわち、サーバ認証部２５は、擬似攻撃のパケットを生成する際に用いた最新のパターンファイルに基づいた攻撃パターンがログに記録されているかどうか検証すると共に、内部監査結果１１２に必要な情報が含まれているか、内部監査結果１１２によって示されるサーバ３のセキュリティ対策が最新のものであるかどうか等を検証する。
【００８１】
検証の結果、最新の攻撃パターンに基づいて更新された攻撃パターンがログに記録されており、内部監査結果１１２が所定の条件を満たしていた場合には、サーバ３のセキュリティレベルを確認することができたとし、サーバ認証部２５は、セキュリティ保証局２の秘密鍵を用いて署名情報を生成し、その署名情報を付加したセキュリティ証明書１１４を生成する。サーバ認証部２５は、サーバとの通信制御部２３および通信部２１を介してサーバ３へセキュリティ証明書１１４を送信する。サーバ３はセキュリティ証明書１１４を受信する（ステップＳ４８）。
【００８２】
クライアント４は、通信の開始時点において、サーバ３に対してセキュリティ証明書１１４の提示を要求する（ステップＳ４９）。サーバ３の通信モジュール４０は、セキュリティ保証局２の署名が付加されたセキュリティ証明書１１４をクライアント４へ送信する（ステップＳ５０）。本変形例においては、高速化のため、サーバ３の内部監査は省略されるものとする。サーバ３は、クライアント４からのセキュリティ証明書の提示要求に備えて、定期的に内部監査を行ってもよい。クライアント４はセキュリティ証明書１１４を受信し、署名検証部４１は、セキュリティ保証局２の公開鍵を用いて、セキュリティ証明書１１４に付加されている署名の検証を行う（ステップＳ５１）。
【００８３】
検証の結果、署名が有効であった場合に、クライアント４はサーバ３へセキュリティ証明書１１４全体を送信するか、セキュリティ証明書１１４に付与されている証明書ＩＤ（後述するシリアル番号）を送信する（ステップＳ５２）。セキュリティ保証局２の通信部２１はセキュリティ証明書１１４または証明書ＩＤを受信し、クライアントとの通信制御部２４を介して失効証明書管理部２９へ出力する。詳細は後述するが、失効証明書管理部２９はセキュリティ証明書１１４が有効であるか失効であるかを検証し、検証結果を示す情報をクライアントとの通信制御部２４へ出力する。クライアントとの通信制御部２４は、通信部２１を介して検証結果の情報をクライアント４へ送信する（ステップＳ５３）。
【００８４】
クライアント４は検証結果の情報を受信し、その情報に基づいて、セキュリティ証明書１１４の有効性を判断する。セキュリティ証明書１１４が失効しておらず、有効なセキュリティ証明書であると判断できた場合に、クライアント４はサーバ３との通信を開始する。
【００８５】
次に、セキュリティ保証局２とサーバ３との間、サーバ３とクライアント４との間、およびセキュリティ保証局２とクライアント４との間の通信に用いられる通信プロトコルについて説明する。従来のＰＫＩにおいては、公開鍵証明書への署名を受けたいサーバは、公の認証局に対して身元情報や公開鍵情報を、郵送等の物理的な経路を使って送っている。場合によっては、これらの情報がネットワーク経由で送られることもあるが、認証局側では何らかの物的証明を参照して、送られてきた情報の正当性の担保を取っている。
【００８６】
しかしながら、セキュリティ証明書の場合、未知の攻撃やウィルスが発見されるたびに証明書の廃棄と更新を図る必要があり、即時性を保つためにも、全てネットワーク経由でオンライン化された処理が行われなければならない。ネットワーク経由で相手を確実に認証し、情報を盗聴されないようにするためにも、通信方式の検討は重要である。
【００８７】
まず、セキュリティ保証局２とサーバ３との間の通信プロトコルを説明する。セキュリティ保証局２とサーバ３との間の通信は、既存の相互認証および暗号化プロトコルで安全な通信路を確保するフェーズから開始する。続いて、開始要求フェーズ、安全性評価フェーズ等が実施され、最後にセキュリティ証明書の発行が行われて終了する。
【００８８】
図７は、セキュリティ保証局２およびサーバ３間の相互認証・暗号化の通信シーケンスを示している。相互認証と暗号化は、既存のＳＳＬ（Secure Socket Layer）やＩＰｓｅｃ等のプロトコルを利用すればよく、証明書発行フェーズと独立しており、各種の相互認証・暗号化プロトコルを適用することができる。図７（ａ）は、ＳＳＬを用いた相互認証・暗号化の通信シーケンス例である。ＴＣＰの３Ｗａｙハンドシェーク（ステップＳ７０１ａ）に続いて、セキュリティ保証局２およびサーバ３はＳＳＬの相互認証・暗号化を行い（ステップＳ７０２ａ）、後述する証明書発行処理を行う（ステップＳ７０３ａ）。ＳＳＬの終了処理（ステップＳ７０４ａ）およびＴＣＰの終了処理（ステップＳ７０５ａ）が行われ、相互認証・暗号化が終了する。
【００８９】
図７（ｂ）は、ＩＰｓｅｃを用いた相互認証・暗号化の通信シーケンス例である。ＩＰｓｅｃの相互認証・暗号化（ステップＳ７０１ｂ）に続いて、セキュリティ保証局２およびサーバ３はＴＣＰの３Ｗａｙハンドシェークを行い（ステップＳ７０２ｂ）、後述する証明書発行処理を行う（ステップＳ７０３ｂ）。ＴＣＰの終了処理（ステップＳ７０４ｂ）およびＩＰｓｅｃの終了処理（ステップＳ７０５ｂ）が行われ、相互認証・暗号化が終了する。
【００９０】
図８は、証明書発行フェーズの通信シーケンス例を示している。図８（ａ）は、証明書発行アプリケーション層で通信処理の確実性を持たせた方式であり、図８（ｂ）は、確実性を下位通信レイヤに委ねて高速性を持たせた方式である。高速性を持たせた方式は、確実性を持たせた方式の処理から確認処理を省いたものとなっている。以下、確実性を持たせた方式を基準にして説明する。
【００９１】
証明書発行のための通信においては、様々な形式およびサイズの情報を交換する必要があるため、自由フォーマットのテキストを通信するのに適したタグ囲み（＜と＞、および＜／と＞の間に、情報の種別を表すテキストが挿入されたタグ同士の間に、情報の内容を表すテキストが挿入される文書構造）を用いることにする。すなわち、通信相手に通知される情報に対してタグが付加された形式のデータが送受信される。タグによって情報の種別が判断（識別）され、タグによって囲まれたテキストを参照することによって、情報の内容が判断（識別）される。
【００９２】
相互認証・暗号化（ステップＳ８０１ａ、ステップＳ８０１ｂ）開始フェーズにおいては、サーバ３はセキュリティ保証局２に対して、セキュリティ証明書の発行のための通信フェーズの開始を通知する。サーバ３は、開始パケットをセキュリティ保証局２へ送信し、セキュリティ証明書の発行要求を通知する（ステップＳ８０２ａ）。セキュリティ保証局２は、そのレスポンスとして確認パケットをサーバ３へ返信する（ステップＳ８０３ａ）。図９は開始パケットおよび確認パケットの内容を示している。「＊」印はオプションである（以下同様）。
【００９３】
続いて、更新・状態通知フェーズにおいて、サーバ３は、セキュリティ対策に関わる更新された情報を、更新・状態通知パケットによってセキュリティ保証局２に通知する（ステップＳ８０４ａ、ステップＳ８０２ｂ）。この更新・状態通知パケットに含まれる情報は、セキュリティ対策システムの状態を示す状態情報（通知情報）であり、内部監査モジュール３９が収集する。セキュリティ保証局２は、更新・状態通知パケットを受信し、確認パケットをサーバ３へ返信する（ステップＳ８０５ａ）。図１０は、更新・状態パケットおよび確認パケットの内容を示している。
【００９４】
図１０において、「name」 印はＯＳやＩＤＳの名前を、「version」 印はそれらのバージョン情報を、「pattern」印はパッチやパターンファイル情報を通知するための識別子である。「UP」 印は、更新された情報を表し、この印のない数値やテキスト情報のみが記載されているものは、更新のない現状を表している。ＶＤＳ等のタグが例示されていないが（例：<status-vds>）、この場合には、ＶＤＳを持っていないか、もしくはＶＤＳに関しては、保証の必要がないことを表している。
【００９５】
多数のサーバのセキュリティ状態を保証するセキュリティ保証局２が各サーバの状態履歴管理をしなくてもよいように、各サーバは、セキュリティ保証局２に通知する情報に現状と更新の両状態の情報を含めることにする。これにより、セキュリティ保証局２はセキュリティ証明書の発行要求単位で発行の可否を判断することができる。もし、セキュリティ保証局２が各サーバの状態の履歴管理機能を有する場合には、各サーバが更新情報のみを通知することによって、セキュリティ保証局２は証明書の発行可否を判断することができる。署名を受ける各サーバの公開鍵情報（<pub-key>＊＊＊</pub-key>参照）も通知される。
【００９６】
続いて、内部監査指示フェーズにおいて、セキュリティ保証局２は、サーバ３に対して、内部監査すべき項目を要求し（ステップＳ８０６ａ、ステップＳ８０３ｂ）、サーバ３はその要求に従った監査結果を報告する（ステップＳ８０７ａ、ステップＳ８０４ｂ）。報告を受けたセキュリティ保証局２は確認パケットをサーバ３へ送信する（ステップＳ８０８ａ）。図１１は内部監査指示パケット、内部監査結果パケット、および確認パケットの内容を示している。
【００９７】
内部監査の結果は、サーバ３のセキュリティ対策システムの状態を示す状態情報であり、更新・状態通知フェーズにおいて、サーバ３がセキュリティ保証局２に通知した状態情報（通知情報）よりも詳細なセキュリティ対策システムの状態を示している。内部監査指示パケットによって、サーバ３が管理しているファイル（例：syslog）や、起動中のプロセス（例：psコマンド）をチェックすることが指示される。これに従い、サーバ３は、要求された情報をテキスト情報として含む内部監査結果パケットをセキュリティ保証局２へ返信する。返信サイズが大きくなる場合には、複数のパケットに分割される場合もある。場合によっては、サーバ３は特徴のみをハッシュ値として通知することもある。また、セキュリティ保証局２が、返信すべき箇所を指定することもあり、例えばキーワードや時刻情報をサーバ３に通知することで、返信すべき箇所を絞り込む。
【００９８】
続いて、外部監査フェーズにおいて、セキュリティ保証局２からサーバ３に対する、攻撃パケット等による外部監査が行われる（ステップＳ８０９ａ、ステップＳ８０５ｂ）。外部監査フェーズに続く外部監査指示フェーズにおいて、セキュリティ保証局２は、サーバ３側に記録された外部監査の結果を収集するため、外部監査指示パケットをサーバ３へ送信する（ステップＳ８１０ａ、ステップＳ８０６ｂ）。サーバ３は、外部監査の結果をテキスト情報として含む外部監査結果パケットをセキュリティ保証局２へ送信する（ステップＳ８１１ａ、ステップＳ８０７ｂ）。外部監査結果パケットを受信したセキュリティ保証局２は確認パケットをサーバ３へ送信する（ステップＳ８１２ａ）。
【００９９】
図１２は、外部監査指示パケット、外部監査結果パケット、および確認パケットの内容を示している。ＩＤＳ等に記録されたログ情報を収集するために、外部監査指示パケットによって、収集すべき情報が指定される。外部監査は、セキュリティ保証局２から実施するとは限らない。また監査を実施するタイミングもまちまちである。さらに、結果ログ等の情報は膨大なサイズになる。これらのことより、収集すべき外部監査結果の箇所を特定する必要があり、セキュリティ保証局２は、外部監査指示パケットによって、外部監査を行ったＩＰアドレスや時刻、キーワード等を指定する情報を通知する。サーバ３は、指定された情報を、テキスト情報である外部監査結果パケットとして返信する。場合によっては、特徴のみをハッシュ値として通知することもある。
【０１００】
続いて、セキュリティ証明書フェーズにおいて、セキュリティ保証局２は、内部監査と外部監査の結果、セキュリティ対策がサーバ３に正しく設定されている場合には、サーバ３に対して、セキュリティ証明書を発行して返信する（ステップＳ８１３ａ、ステップＳ８０８ｂ）。サーバ３にセキュリティ対策が正しく設定されていない場合や、サーバ３から情報を正しく受け取れなかった場合には、セキュリティ保証局２はエラー情報（未対策通知パケット）を返信する。セキュリティ証明書を受け取ったサーバ３は確認パケットをセキュリティ保証局２へ送信する。図１３はセキュリティ証明書パケットおよび未対策通知パケットの内容を示している。
【０１０１】
セキュリティ証明書には、発行者のＩＰアドレスと名前、バージョン番号、署名方式、署名の発行年月日、有効期限、サーバ名、サーバの公開鍵情報、セキュリティレベルが付与される。場合によっては、ＯＳやＩＤＳ・ＶＤＳの状態が正しいということを示す情報も含まれる。また、後述するように、ＯＳやＩＤＳ・ＶＤＳの状態に関する情報が、セキュリティ保証局２の公開鍵によって埋め込まれる場合もある。セキュリティ保証局２は、この情報を自身の秘密鍵で解くことによって、サーバ３の状態を示す情報を取り出し、セキュリティ証明書単位での有効性の確認を行う。
【０１０２】
セキュリティ証明書の末尾には署名情報が付与される。署名情報として、ＯＳやＩＤＳの状態を表す署名と、セキュリティ証明書全体の正当性を表す署名とがある。ＯＳやＩＤＳの状態をテキスト文のまま記載してしまうと、悪意の侵入者にセキュリティ対策情報（どのようなセキュリティ対策が施されているのかを表すセキュリティ対策の種別等を示す情報）を公開してしまうことが予想されるため、セキュリティ保証局２は、セキュリティ対策情報を抽象化した安全指数（<level>＊＊＊</level>参照）をセキュリティ証明書に付加する。セキュリティ保証局２はセキュリティ対策情報と安全指数との対応表を管理しており、サーバ３から通知されたセキュリティ対策情報に基づいて、サーバ３の安全指数を決定する。もし、内部監査や外部監査の結果、サーバ３のセキュリティ対策が十分でないと判断した場合には、セキュリティ保証局２は、未対策通知パケットによって問題箇所をサーバ３に通知する。続いて、相互認証・暗号化終了フェーズを経て、通信が終了する（ステップＳ８１５ａ、ステップＳ８０９ｂ）。
【０１０３】
本変形例においては、セキュリティ保証局２がセキュリティ証明書を発行しているが、前述した変形例と同様に、サーバ３が仮のセキュリティ証明書をセキュリティ保証局２へ送信し、セキュリティ証明書に対して、セキュリティ保証局２が署名を施すようにしてもよい。この場合の通信においても、本変形例と同様に、タグ囲みを用いた通信が行われる。
【０１０４】
次に、サーバ３およびクライアント４間の通信プロトコルを説明する。図１４はサーバ３およびクライアント４間の通信シーケンスを示している。図１４においては、証明書要求アプリケーションがＴＣＰレイヤの上で動いている様子が示されている。図１４（ａ）は、通信処理の確実性を持たせた方式であり、図１４（ｂ）は、確認処理を省いて高速性を持たせた方式である。
【０１０５】
ＴＣＰの３Ｗａｙハンドシェーク（ステップＳ１４０１ａ、ステップＳ１４０１ｂ）に続いて、相互認証および暗号化が行われ（図示せず）、確実性を持たせた方式では開始パケットおよび確認パケットの送受信が行われる（ステップＳ１４０２ａ、ステップＳ１４０３ａ）。続いて、クライアント４は、サーバ３に対して、証明書要求パケットを送信する（ステップＳ１４０４ａ、ステップＳ１４０２ｂ）。サーバ３は証明書要求パケットを受信し、証明書要求パケットによる要求に基づいて、セキュリティ証明書パケットをクライアント４へ送信する（ステップＳ１４０５ａ、ステップＳ１４０３ｂ）。
【０１０６】
図１５は、証明書要求パケットおよびセキュリティ証明書パケットの内容を示している。セキュリティ証明書パケットには、発行者名、バージョン、署名方式、発効日時、有効期限、サーバ名、セキュリティレベル等の情報がテキストとして含まれている。場合によっては、ＯＳやＩＤＳの状態が正しいことを通知するための情報も含まれる（<os-status>＊＊＊</os-status>および<ids-status>＊＊＊</ids-status>参照）。最後にセキュリティ保証局２の署名情報が付与される（<hash>＊＊＊</hash>参照）。
【０１０７】
確実性を持たせた方式では、セキュリティ証明書パケットを受信したクライアント４は、確認パケットをサーバ３へ送信する（ステップＳ１４０６ａ）。続いて、ＴＣＰの終了処理が行われて、処理が終了する（ステップＳ１４０７ａ、ステップＳ１４０４ｂ）。
【０１０８】
次に、セキュリティ保証局２およびクライアント４間の通信プロトコルを説明する。クライアント４側でのセキュリティ証明書の検証は、処理負荷の軽減と、セキュリティに関する確実性との観点から次の２つのレベルがある。
Ｌｅｖｅｌ１）既に取得しているセキュリティ保証局２の公開鍵を用いたローカル検証
Ｌｅｖｅｌ２）セキュリティ証明書の失効状態を確認するためにセキュリティ保証局２に問い合わせるオンライン検証
【０１０９】
Ｌｅｖｅｌ１を実現するには、既存のＰＫＩモデルと同様に、クライアント４が予めセキュリティ保証局２の公開鍵証明書を取得しておくことによって、セキュリティ証明書に付随する署名の有効性を検証することができる。クライアント４は外部との通信を必要とせず、処理負荷は軽い。
【０１１０】
しかしながら、未知の攻撃やウィルスが新たに出回り始めた場合に、セキュリティ証明書の有効性を確認する必要が生じる。有効期限内のセキュリティ証明書についても、クライアント４からセキュリティ保証局２に対して、失効状態の確認を頻繁に図ることが想定される。このとき、確実性を重視したＬｅｖｅｌ２のオンライン検証が必要になる。以下、Ｌｅｖｅｌ２の方式を実現する手法を説明する。図１６はクライアント４およびセキュリティ保証局２間のＬｅｖｅｌ２の通信シーケンスを示している。図１６（ａ）は、通信処理の確実性を持たせた方式であり、図１６（ｂ）は、確認処理を省いて高速性を持たせた方式である。
【０１１１】
ＴＣＰの３Ｗａｙハンドシェーク（ステップＳ１６０１ａ、ステップＳ１６０１ｂ）に続いて、相互認証および暗号化が行われ（図示せず）、確実性を持たせた方式では開始パケットおよび確認パケットの送受信が行われる（ステップＳ１６０２ａ、ステップＳ１６０３ａ）。続いて、クライアント４は、サーバ３から受信したセキュリティ証明書をセキュリティ保証局２へ送信し、セキュリティ証明書の有効性の確認を要求する（ステップＳ１６０４ａ、ステップＳ１６０２ｂ）。
【０１１２】
セキュリティ保証局２はセキュリティ証明書を受信し、自身の公開鍵でセキュリティ証明書に署名したＯＳやＩＤＳの状態情報を、秘密鍵を用いて取り出し、その有効性を確認し、有効性の確認結果をクライアント４に返信する（ステップＳ１６０５ａ、ステップＳ１６０３ｂ）。このとき、クライアント４には、セキュリティ保証局２からの情報であることを保証するために、返信パケットの全体に対してセキュリティ保証局２の秘密鍵で署名した情報が送信される。図１７はセキュリティ証明書パケットの内容、および有効性の確認結果である結果パケットの内容を示している。確実性を持たせた方式では、確認結果を示すパケットを受信したクライアント４は確認パケットをセキュリティ保証局２へ送信する（ステップＳ１６０６ａ）。続いて、ＴＣＰの終了処理（ステップＳ１６０７ａ、ステップＳ１６０４ｂ）が行われ、処理が終了する。
【０１１３】
次に、セキュリティ保証局２によるセキュリティ証明書の発行および失効の手法を説明する。従来のＰＫＩでは、各サーバに発行された証明書は、シリアル番号（前述した証明書ＩＤ）で管理されている。各証明書の有効期限は数年単位で設定されており、ひとたび発行された証明書の殆どが、有効期限内に失効することはない。よって、発行（更新）と失効の頻度は低く、個々の履歴をシリアル番号で管理することは可能である。このシリアル番号をＣＲＬ（Certificate Revocation List）に登録することによって、証明書の管理が実現されている。
【０１１４】
しかしながら、本実施形態におけるセキュリティ証明書の場合、新たな攻撃やウィルスが発見されるたびに、ＯＳやＩＤＳ・ＶＤＳの設定ファイルが更新されることになり、発行（更新）と失効の頻度が高く、セキュリティ保証局２は膨大な数のセキュリティ証明書の状態を管理することになる。以下では、従来のＣＲＬによる管理手法の適用も検討するが、セキュリティ保証局２側で、発行したセキュリティ証明書の履歴管理を行う必要のない管理手法についても検討が必要である。
【０１１５】
以下では、セキュリティ証明書の中に、セキュリティ保証局２のみが読み出せるサーバ３のセキュリティ対策情報を持たせることによって、セキュリティ保証局２はセキュリティ証明書を参照するだけで、その有効性（失効性）を判定することができる方式を説明する。これは、サーバ３のセキュリティ対策情報を、クライアント４に取得されないようにするために、セキュリティ証明書内に暗号化して保存する手法であり、悪意のクライアント対策を考慮した安全性を重視した方式である。
【０１１６】
また、頻繁にセキュリティ証明書の有効性を確認しなければならない本実施形態の場合、クライアント４がセキュリティ保証局２に問い合わせる頻度が高くなり、セキュリティ保証局２側で輻輳する可能性もある。したがって、発行した個々のセキュリティ証明書を管理するのではなく、グループ単位で有効性を判定する手法についても検討する必要がある。
【０１１７】
以下では、失効処理の負荷の軽減を目的として、同一種類のＯＳやＩＤＳ・ＶＤＳが適用されているサーバに対して、同一種類のセキュリティ証明書を発行することで、セキュリティ証明書の種別ごとに一斉に失効させる手法を説明する。これによって、セキュリティ証明書の失効判定処理の簡易化を図ることができる。
【０１１８】
まず、ＣＲＬによるセキュリティ証明書の管理手法を本実施形態に適用した場合を説明する。セキュリティ保証局２は、発行した個々のセキュリティ証明書に、固有のシリアル番号を付与する。セキュリティ証明書を失効させる際には、セキュリティ保証局２は、この番号をＣＲＬに登録する。この手法は、失効管理を実現する従来のＰＫＩモデルと同じ方式である。この場合、ＯＳやＩＤＳ・ＶＤＳに関する情報をセキュリティ証明書に付与する必要はない。セキュリティ証明書の有効性を判断する場合、セキュリティ保証局２の失効証明書管理部２９は、セキュリティ証明書に付与されているシリアル番号とＣＲＬ中のシリアル番号とを照合し、両者が一致した場合に、そのセキュリティ証明書が失効状態である（有効でない）と判断する。
【０１１９】
次に、セキュリティ証明書の中にサーバ３のセキュリティ対策情報（どのようなセキュリティ対策が施されているのかを表すセキュリティ対策種別等を示す情報）を、セキュリティ保証局２のみが読み出せるように格納する手法を説明する。セキュリティ保証局２から発行されたセキュリティ証明書にサーバ３のセキュリティ対策情報を、セキュリティ保証局のみが読み出せる手法で埋め込んでおくことによって、クライアント４からセキュリティ保証局２に対して、有効性に関する問い合わせがあった場合にも、セキュリティ保証局２は、セキュリティ証明書の情報を参照するだけで、その有効性を判定することができる。ここで注意すべきことは、セキュリティ証明書の中に、ＯＳやＩＤＳ・ＶＤＳの名前やバージョン等の情報を直接（誰でも読み出せる形で）埋め込まないことである。
【０１２０】
セキュリティ保証局２のサーバ認証部２５は、セキュリティ証明書を発行する際に、セキュリティ証明書に付与するセキュリティ対策情報として、サーバ３から通知されたＯＳやＩＤＳ・ＶＤＳの名前およびバージョン・パターンファイル情報と、パディングのための乱数とを１つの情報として扱い、この情報に対して、自身の公開鍵で暗号化を施す。セキュリティ保証局２は、暗号化して得た暗号データをセキュリティ証明書に付加する。暗号化の様子は、図１３等における証明書タグ<secret-os> ＊＊＊ </secret-os> や <secret-ids>＊＊＊ </secret-ids> で表されている。
【０１２１】
セキュリティ保証局２は各セキュリティ証明書の固有のシリアル番号を管理することはせず、セキュリティ対策の種別を示すＯＳやＩＤＳ・ＶＤＳのバージョンと、その有効性を示す情報とが関連付けられたテーブル（失効情報テーブル）を記憶部２８に格納している。セキュリティ証明書の有効性を判断する際に、サーバ認証部２５は、セキュリティ証明書に含まれる、暗号化されたセキュリティ対策情報をセキュリティ保証局２の秘密鍵で復号化する。サーバ認証部２５は、記憶部２８から失効情報テーブルを読み出し、復号化によって得たセキュリティ対策情報の内容と照合することによって、セキュリティ証明書の有効性を判断する。すなわち、セキュリティ証明書に含まれていたセキュリティ対策情報によって示されるＯＳ等のバージョンが、失効情報テーブル上で失効となっていた場合、サーバ認証部２５は、セキュリティ証明書が失効していると判断する。
【０１２２】
この手法によれば、セキュリティ保証局２は、膨大な数の個々のセキュリティ証明書のシリアル番号を管理する必要がなくなるので、セキュリティ保証局２において必要な記録容量を削減し、セキュリティ保証局２の管理コストを低減することができる。また、サーバ３のセキュリティ対策情報が暗号化されてセキュリティ証明書に付加されているので、サーバ３のセキュリティ対策情報が漏洩する危険性を低減することができる。
【０１２３】
次に、種別ごとにセキュリティ証明書を一斉に失効させる手法を説明する。サーバ認証部２５は、同一種類のＯＳやＩＤＳ・ＶＤＳが適用されている複数のサーバに対して、同一種類の識別情報を有するセキュリティ証明書を発行する。サーバ認証部２５は、セキュリティ対策種別を識別するシリアル番号をセキュリティ証明書に付与する。セキュリティ対策種別は、ＯＳやＩＤＳ・ＶＤＳのバージョンによって示される。
【０１２４】
記憶部２８には、セキュリティ対策種別およびそのシリアル番号と、有効性を示す情報とが関連付けられた失効情報テーブルが格納されている。サーバ認証部２５は、クライアント４から受信されたサーバ３のセキュリティ証明書に含まれるシリアル番号と、記憶部２８から読み出した失効情報テーブル中のシリアル番号とを照合する。両者が一致した場合、サーバ認証部２５は、失効情報テーブルの内容に基づいて、そのバージョンの有効性を判断する。そのバージョンが失効状態である場合、サーバ認証部２５はセキュリティ証明書が失効状態である（有効でない）と判断する。
【０１２５】
セキュリティ証明書が失効するタイミングは、セキュリティ証明書の有効期限内にＯＳのバージョンが更新される場合や、ＩＤＳ・ＶＤＳの検知パターンファイルが公開される場合である。上記のように、同一種類のセキュリティ対策種別を有する複数のサーバに対して、セキュリティ対策種別に関して同一内容のセキュリティ証明書が発行されるため、ＯＳ、ＩＤＳ、およびＶＤＳの個々のセキュリティ対策種別ごとにセキュリティ証明書が一斉に失効することになる。
【０１２６】
失効は、セキュリティ対策種別ごとに生成されたセキュリティ証明書内のシリアル番号で管理される。この手法でセキュリティ保証局２から公開される失効情報は、有効期限内に失効することになったセキュリティ証明書のシリアル番号のみとする。図１３等に示されるセキュリティ証明書中の<secret-os>＊＊＊</secret-os> や <secret-ids>＊＊＊</secret-ids> で表されている情報の箇所へ、セキュリティ対策種別ごとのシリアル番号が付与される。この場合、セキュリティ証明書全体へのシリアル番号は不要になる。
【０１２７】
以下、セキュリティ対策種別ごとに付与するシリアル番号から、セキュリティ対策情報を推測し難くする手法について、ＯＳ種別とバージョンを例にして説明する。ＯＳには複数種類あり、そのバージョンにも様々なものがある。図１８は、シリアル番号および失効状態のＯＳならびにバージョン情報を管理する失効情報テーブルの様子を示している。このテーブルは、セキュリティ保証局２の失効証明書管理部２９によって作成されて、管理される。また、このテーブルは記憶部２８に格納されている。
【０１２８】
シリアル番号は、Ａ、Ｂ、Ｃ・・・で表されるグループＩＤと昇順数値とによって構成されている。失効状態に関しては、あるグループのある数値が失効した場合、同じグループ内のその数値以下の全ての数値が失効となる。例えばグループＤの００４まで失効した場合、Ｄグループのそれ以下（０００〜００３）の数値が関連付けられたセキュリティ証明書は全て失効される。図１８（ａ）においては、グループＢの０００〜００２およびグループＤの０００〜００１に関連付けられたセキュリティ証明書は全て失効している。失効情報テーブルには、グループＢの００２およびグループＤの００１が失効しているという情報が含まれている。その数値以下の数値は全て失効しているから、全ての昇順数値に対して失効しているか否かの情報（フラグ等）を用意する必要はない。これによって、セキュリティ保証局２において必要な記録容量を削減し、セキュリティ保証局２の管理コストを低減することができる。
【０１２９】
セキュリティ対策情報を推定され難くするために、同じＯＳとバージョンであっても、複数のグループＩＤと複数の数値で管理されることにする。図１８には、ＯＳｘｘｘとＯＳｙｙｙが複数のグループで管理されている様子や、ＯＳｘｘｘ−ｖ１．１とＯＳｚｚｚ−ｖ１．２が複数の数値で管理されている様子が示されている。同じＯＳとバージョンを持つサーバがあったとしても、セキュリティ証明書によってはグループＩＤや昇順数値が異なる場合もあり、互いに同じ設定であることを認識できないようになる。推定の困難性は、グループＩＤの数や昇順数値の数に依存する。
【０１３０】
ＯＳｙｙｙのバージョン１．３までが失効状態であった場合（図１８（ａ））、Ｄグループの０００〜００１が失効となっている。Ｄグループの００２以後には別のＯＳｘｘｘの管理が割り当てられている。さらに時間が進み、ＯＳｘｘｘのバージョン１．２まで失効されていることを想定する（図１８（ｂ））。このとき、Ａグループの００３まで全て失効された状態となり、Ａ−００４以後には別のＯＳｙｙｙを割り当てることができる。
【０１３１】
図１８（ａ）の状態では、Ａ−００３は失効しておらず、この状態でＡ−００４以後に別のＯＳｙｙｙを割り当ててしまうと、ＯＳｘｘｘ−ｖ１．２よりもＯＳｙｙｙの方が先に失効してしまう可能性がある。したがって、図１８（ｂ）の状態となってから、Ａ−００４以後に別のＯＳｙｙｙが割り当てられるようになる。失効証明書管理部２９は、シリアル番号の昇順数値を付与する際に、上記のように、ある昇順数値が付与されたバージョンが失効であった場合に、同一グループのその数値以下の昇順数値が付与されたバージョンが全て失効状態となっているという関係を満たすように、昇順数値を付与する。
【０１３２】
悪意のサーバが様々なOSやバージョン情報をセキュリティ保証局２に申請して、多数の証明書を集めることによって、シリアル番号の対応表を推定することができる可能性がある。この攻撃に対しては、セキュリティ保証局２が、セキュリティ証明書の発行頻度を制限することによって、防ぐことができる。
【０１３３】
セキュリティ保証局２はシリアル番号と、その番号を最後に発行した日時情報とを管理しておく。この日時情報を基に、有効期限の切れたセキュリティ証明書のシリアル番号は公開しないことにして、失効情報の量を軽減させる。図１８（ｂ）では、Ｂ−００２が、有効期限切れのセキュリティ証明書に付与されたシリアル番号であり、Ａ−００３とＤ−００２の２つが、失効情報としてセキュリティ保証局２から公開される。
【０１３４】
上述した手法によれば、セキュリティ対策種別に関して同一内容のセキュリティ証明書の有効性をグループ単位の数値で判断することができ、セキュリティ保証局２の負荷を軽減することができる。また、失効したＯＳ等のバージョンのグループＩＤと昇順数値を公開しておくことによって、クライアント側でも容易にセキュリティ証明書の失効判定を行うことができる。
【０１３５】
また、同一のＯＳやＩＤＳ・ＶＤＳ等のバージョンに対して、グループＩＤおよび昇順数値の組を複数割り当てることによって、サーバのセキュリティ対策情報を推測し難くすることができる。さらに、前述した、サーバ３のセキュリティ対策情報をセキュリティ保証局２が暗号化してセキュリティ証明書に埋め込む手法と比較して、セキュリティ証明書のサイズを小さくすることができる。
【０１３６】
なお、本変形例において説明したセキュリティ証明書の発行および失効の手法を、前述した変形例に適用してもよい。
【０１３７】
次に、サーバ３の内部監査モジュール３９の耐タンパ化を図る手法を説明する。セキュリティ証明書の内容を保証するために、内部監査モジュール３９の役割は重要である。もし内部監査モジュール３９に関わる処理が攻撃され、ＩＤＳ３２やＶＤＳ３３が停止しているにも関わらず、サーバ３がセキュリティ証明書をクライアント４に返信していたら、本実施形態によるＰＫＩ基盤モデルの信用が失われてしまうことになる。
【０１３８】
攻撃例として、i）内部監査モジュール３９が起動しているサーバ３のＯＳ自体が攻撃されて乗っ取られることで、ＯＳが内部監査モジュール３９に偽の情報を返信する攻撃がある。また、ii）内部監査モジュール３９自体が攻撃されて、なりすまされることで、セキュリティ保証局２と偽の情報を交換する攻撃や、クライアント４に偽のセキュリティ証明書を返信してしまう攻撃が考えられる。そこで本変形例では、最も重要な役割を果たす内部監査モジュール３９の耐タンパ化を、ＴＣＧ（Trusted Computing Group）で検討されているＴＰＭ（Trusted Platform Module）の技術を用いて実現する手法と、スマートカード（ＩＣカード）を用いて実現する手法とを提案する。
【０１３９】
まず、ＴＣＧについて説明する。ＴＣＧとは、ハードウェアからＢＩＯＳ、ＯＳに至るまで、アプリケーションを実行する環境を、信頼できるプラットフォームとして実現することを目指す業界標準化団体である。具体例として、コンピュータ上にハードウェアチップを組み込み、ソフトウェアから不正に操作することができない秘密情報（暗号鍵等）をそのハードウェアチップに格納するといったことが挙げられる。このチップのことをＴＰＭという。いわゆる、コンピュータに内蔵されたセキュリティチップのことである。
【０１４０】
ＴＰＭを構成する機能として必要なものを以下に示す。
（１）プラットフォーム完全性の計測：ＢＩＯＳ、ＯＳ、ソフトウェアの改竄を発見するための、ソフトウェアのハッシュ値を保存する機能。
（２）プラットフォームの認証：正当なＴＰＭが使用されていることを保障するための、ＴＰＭ内に格納する秘密鍵の生成、保持機能。
（３）保護メモリ領域：秘密鍵を安全に保管するための、保護された記憶機能。
（４）暗号処理用コプロセッサ：暗号処理を安全に行うための公開鍵暗号演算、乱数発生、ハッシュ演算機能。
【０１４１】
ＴＰＭが上述した機能を備えることによって、図１９に示されるように、ＴＰＭの実装位置を信頼点として、ＯＳ、Ｂｏｏｔ  Ｌｏａｄｅｒ、ＢＩＯＳ等の完全性の確認が可能となり、信頼性が保たれる（信頼の連鎖）。例えば、ＴＰＭにはＯＳ等のハッシュ値が格納されており、ＯＳ等が改竄された場合には、そのハッシュ値が変化するので、改竄できないＴＰＭ中のハッシュ値と比較することによって、ＯＳ等の改竄の有無を検出することができる。
【０１４２】
一方、スマートカード（ＩＣチップとも呼ばれる）とは、ＣＰＵやメモリ、セキュリティ回路等のＩＣチップを組み込んだクレジットカード大のプラスチックカードである。スマートカードは、外部からの物理的な攻撃を受けた場合、チップ自体が破損する。また、守るべきプログラムはＲＯＭに焼き付けられており、外部のソフトウェア等でそのプログラムを書き換えることは不可能である。また、スマートカードは、重要な情報に暗号化を施して記憶することができる等の特徴を持っている。セキュリティ保証基盤で利用するスマートカードは、サーバ３のインタフェースに差し込む形態とし、暗号化等の演算能力、秘密情報の記憶領域、通信機能をスマートカードに持たせる。
【０１４３】
サーバ３内部にセキュリティチップを持たせて、そこで守るべき秘密情報と、この秘密情報を基に間接的に守られる情報を以下で列挙する。ちなみに、セキュリティチップを信頼点として、信頼の連鎖により間接的に守られる情報は、通常の記憶領域（ハードディスク等）で管理される。
【０１４４】
ＴＰＭやスマートカードの記憶領域、計算処理能力、通信能力が高い場合、守るべき情報と信頼の連鎖で守られる情報は図２０（ａ）の通りとなる。セキュリティチップの能力が高い場合には、ＢＩＯＳ、Ｂｏｏｔ  Ｌｏａｄｅｒ、ＯＳの他、内部監査モジュール３９や通信インタフェース（通信モジュール４０）の機能を実現する処理回路自体をセキュリティチップ内に実装することができる。また、ＴＰＭやスマートカードの記憶領域、計算処理能力、通信能力が低い場合、守るべき情報と信頼の連鎖で守られる情報は図２０（ｂ）の通りとなる。セキュリティチップの能力が低い場合には、内部監査モジュール３９等の機能を実現する処理回路自体はセキュリティチップとは別のハードウェアによって構成し、セキュリティチップ内に内部監査モジュール３９等のハッシュ値を格納しておく。
【０１４５】
次に、セキュリティＧＷ（ゲートウェイ）に対して、耐タンパ化されたモジュールを実装した例を説明する。ＴＰＭやスマートカードを用いて信頼点を作成するには、サーバにセキュリティチップを実装するよりも、ブロードバンドルータやホームＧＷに実装してセキュリティＧＷとする方が容易に実現できる。図２１は、セキュリティＧＷにセキュリティチップを実装した場合の通信システムの構成を示している。
【０１４６】
図において、セキュリティＧＷ９に高性能なセキュリティチップ９１が実装され、セキュリティＧＷ９自身のＯＳ、内部監査モジュール、通信モジュール、秘密鍵が、セキュリティチップ９１によって管理されている。セキュリティ保証局２やクライアント４との通信処理は、セキュリティチップ９１内に設けた通信モジュールを経由して行われる。内部監査モジュールは、セキュリティＧＷ９自身のＩＤＳ・ＶＤＳの状態を監視する。また、セキュリティチップ９１は、ＬＡＮに接続されている各種機器（図２１の各種端末１２やサーバ１３等）のＯＳやアプリケーション、場合によってはＶＤＳ等の状態を、外部監査によって監視する。
【０１４７】
なお、本変形例において説明した内部監査モジュール３９の耐タンパ化の手法を、前述した変形例に適用してもよい。
【０１４８】
上述したように本実施形態においてサーバ３は、自身のセキュリティレベル（通信上の安全性）を示すＩＤＳ３２またはＶＤＳ３３に関しての、ＡＣの発行に必要な情報１０４をセキュリティ保証局２へ送信する。セキュリティ保証局２は、ＡＣの発行に必要な情報１０４に基づいてサーバ３のセキュリティレベル（通信上の安全性）を検証し、セキュリティレベルを確認することができた場合に、ＡＣ１０５を発行し、サーバ３へ送信する。また、サーバ３は、クライアント４からの接続要求があった場合に、クライアント４へＡＣ１０５を送信し、クライアント４はＡＣ１０５に基づいて、サーバ３のセキュリティレベルを検証する。
【０１４９】
上記により、クライアント４は、サーバ３のセキュリティレベルが、第三者機関であるセキュリティ保証局２によって証明されていることをサーバ３との通信前にＡＣ１０５から知ることができる。したがって、セキュリティ保証局２、サーバ３、およびクライアント４に対して上記のような機能を持たせることによって、通信相手がセキュリティ対策を施していることを保証し、より安全なネットワーク基盤を構成することができるようになる。
【０１５０】
また、本実施形態の他の動作によれば、サーバ３は、本人性（識別性）を示すＰＫＣ１０２をセキュリティ保証局２へ送信し、セキュリティ保証局２は、ＰＫＣ１０２に基づいてサーバ３の本人性を検証し、本人性およびセキュリティレベルを確認することができた場合に、ＡＣ１０５を発行し、サーバ３へ送信する。さらに、サーバ３は、クライアント４からの接続要求があった場合に、クライアント４へＰＫＣ１０２を送信し、クライアント４は、ＰＫＣ１０２に基づいて、サーバ３の本人性を検証する。上記により、通信相手がセキュリティ対策を施していることをより確実に保証することができる。
【０１５１】
また、本実施形態の他の動作によれば、セキュリティ保証局２およびサーバ３は、公開鍵暗号認証方式またはパスワード認証方式による両方向の認証に続いて暗号通信を行い、セキュリティ保証局２はサーバ３を遠隔操作し、ＡＣの発行に必要な情報１０４に相当する情報をサーバ３から取得する。あるいは両方向の認証に続いてサーバ３がＡＣの発行に必要な情報を主体的にセキュリティ保証局２へ送信する。これにより、上記と同様の効果を得ることができると共に、悪意のサーバがＩＤＳやＶＤＳによる通信の監視を行っていないにもかかわらず、ＡＣの発行依頼を行う事態を防止し、サーバ３のセキュリティレベルをより確実に確認および保証することができる。
【０１５２】
また、本実施形態の他の動作によれば、サーバ３は、難読化等により耐タンパ性を有するプログラムに従って、ＩＤＳ３２またはＶＤＳ３３の状態を示す状態情報を生成してセキュリティ保証局２へ送信し、セキュリティ保証局２は状態情報を受信し、状態情報の内容が、ＡＣの発行に必要な情報１０４に含まれる情報の内容と一致するかどうか検証する。これにより、サーバ３のセキュリティレベルをより確実に確認および保証することができる。
【０１５３】
また、本実施形態の他の動作によれば、セキュリティ保証局２は、最新のパターンファイルに基づいた攻撃をサーバ３に対して行い、サーバ３のＩＤＳ３２またはＶＤＳ３３は、セキュリティ保証局２からの受信等により予め保持する最新のパターンファイルに基づいて、セキュリティ保証局２による攻撃を検知し、ログに記録する。サーバ３はログをセキュリティ保証局２へ送信し、セキュリティ保証局２は、サーバ３に対して行った攻撃がログに記録されているかどうか検証することにより、サーバ３が最新のパターンファイルに基づいたセキュリティ対策を行っているかどうか確認する。これにより、サーバ３のセキュリティレベルをより確実に確認および保証することができる。
【０１５４】
また、本実施形態の変形例によれば、サーバ３がＩＤＳ３２およびＶＤＳ３３の状態等を確認して仮のセキュリティ証明書１０９を発行し、このセキュリティ証明書１０９に対してセキュリティ保証局２が署名を行うことにより、セキュリティ保証局２が実施していたセキュリティ証明書の発行処理がサーバ３側に移るため、セキュリティ保証局２が多数のサーバを管理する場合にはその処理負荷を軽減することができる。
【０１５５】
また、本実施形態の他の変形例によれば、セキュリティ保証局２とサーバ３との間で行われるセキュリティ証明書の発行のための通信において、通信相手に通知される情報に対して、その情報を識別するタグが付加される。これによって、データに含まれるタグの順番等に依存せずに、情報を判別することができるので、セキュリティ保証局２およびサーバ３が様々な形式やサイズの情報を効率よく交換することができる。
【０１５６】
また、本実施形態の他の変形例によれば、セキュリティ保証局２は、サーバ３のセキュリティ対策の種別を示すセキュリティ対策情報に対して、自身の公開鍵で暗号化を施して暗号データを生成し、その暗号データをセキュリティ証明書に付加する。セキュリティ保証局２は、クライアント４からセキュリティ証明書の有効性の確認を要求された場合に、セキュリティ証明書に付加された暗号データを自身の秘密鍵で復号化することによって得たセキュリティ対策情報に基づいて、セキュリティ証明書の有効性を判断する。これによって、セキュリティ保証局２は、膨大な数のセキュリティ証明書の個々のシリアル番号を管理する必要がなくなるので、セキュリティ保証局２において必要な記録容量を削減し、セキュリティ保証局２の管理コストを低減することができる。さらに、サーバ３のセキュリティ対策情報が暗号化されてセキュリティ証明書に付加されているので、サーバ３のセキュリティ対策情報が漏洩する危険性を低減することができる。
【０１５７】
また、本実施形態の他の変形例によれば、セキュリティ保証局２は、同一のセキュリティ対策種別を有する複数のサーバに対して、同一のシリアル番号を有するセキュリティ証明書を発行する。換言すると、セキュリティ保証局２は、セキュリティ対策種別ごとに異なるシリアル番号をセキュリティ証明書に付与する。セキュリティ保証局２は、シリアル番号とセキュリティ対策種別、ならびに有効性（失効状態であるかどうか）を示す情報が関連付けられた失効情報テーブルと、セキュリティ証明書に付加されたシリアル番号とに基づいて、セキュリティ証明書の失効状態を判断する。これによって、セキュリティ証明書の有効性の判断に係るセキュリティ保証局２の負荷を軽減することができる。
【０１５８】
また、本実施形態の他の変形例によれば、ＴＰＭやスマートカード等のセキュリティチップをサーバ３に実装し、セキュリティチップ自体に内部監査モジュール３９の処理回路を設ける、あるいはセキュリティチップに内部監査モジュール３９のハッシュ値を格納することによって、内部監査モジュール３９の改竄を防止し、サーバ３のセキュリティレベルをより確実に確認および保証することができる。
【０１５９】
以上、図面を参照して本発明の実施形態について詳述してきたが、具体的な構成はこれらの実施の形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計変更等も含まれる。
【図面の簡単な説明】
【０１６０】
【図１】本発明の一実施形態による通信システムの構成を示すブロック図である。
【図２】同実施形態によるセキュリティ保証局の構成を示すブロック図である。
【図３】同実施形態によるサーバの構成を示すブロック図である。
【図４】同実施形態における属性証明書の内容を確認するための表示を示す参考図である。
【図５】同実施形態の変形例による通信システムの構成を示すブロック図である。
【図６】同実施形態の他の変形例による通信システムの構成を示すブロック図である。
【図７】同実施形態の他の変形例における通信シーケンスを示すシーケンス図である。
【図８】同実施形態の他の変形例における通信シーケンスを示すシーケンス図である。
【図９】同実施形態の他の変形例におけるパケットの内容を示す参考図である。
【図１０】同実施形態の他の変形例におけるパケットの内容を示す参考図である。
【図１１】同実施形態の他の変形例におけるパケットの内容を示す参考図である。
【図１２】同実施形態の他の変形例におけるパケットの内容を示す参考図である。
【図１３】同実施形態の他の変形例におけるパケットの内容を示す参考図である。
【図１４】同実施形態の他の変形例における通信シーケンスを示すシーケンス図である。
【図１５】同実施形態の他の変形例におけるパケットの内容を示す参考図である。
【図１６】同実施形態の他の変形例における通信シーケンスを示すシーケンス図である。
【図１７】同実施形態の他の変形例におけるパケットの内容を示す参考図である。
【図１８】同実施形態の他の変形例における失効情報テーブルの内容を示す参考図である。
【図１９】同実施形態の他の変形例における内部監査モジュールの耐タンパ化を説明するための参考図である。
【図２０】同実施形態の他の変形例における守るべき情報と守られる情報を説明するための参考図である。
【図２１】同実施形態の他の変形例における通信システムの構成を示すブロック図である。
【図２２】従来の公開鍵証明書および属性証明書のデータ構造を示す参考図である。
【図２３】従来の認証局および属性認証局による公開鍵証明書および属性証明書の発行・指定関係を示す参考図である。
【図２４】従来の失効証明書リストのデータ構造を示す参考図である。
【図２５】従来のＩＤＳの構成を示すブロック図である。
【符号の説明】
【０１６１】
１・・・認証局、２・・・セキュリティ保証局、３，１３・・・サーバ、４・・・クライアント、５・・・ＩＤＳ・ＶＤＳベンダ、６・・・属性認証局、７・・・端末、８，３２・・・ＩＤＳ、９・・・セキュリティＧＷ、１０・・・インターネット、１１ａ，１１ｂ・・・ネットワーク、１２・・・各種端末、２１，３１・・・通信部、２２・・・ＩＤＳ・ＶＤＳベンダからの情報取得部、２３・・・サーバとの通信制御部、２４・・・クライアントとの通信制御部、２５・・・サーバ認証部、２６・・・サーバへのＩＤＳ・ＶＤＳパターンファイル適用部、２７・・・属性証明書発行部、２８，３８・・・記憶部、２９・・・失効証明書管理部、３３・・・ＶＤＳ、３４・・・クライアント通信制御部、３５・・・クライアントからのセッション受付部、３６・・・ＩＤＳ／ＶＤＳの起動監視部、３７・・・ＳＣＡとの通信制御部、３９・・・内部監査モジュール、４０・・・通信モジュール、４１・・・署名検証部、８１・・・パケット取得部、８２・・・攻撃検査部
【図１】
2006139747.tif 000003
【図２】
2006139747.tif 000004
【図３】
2006139747.tif 000005
【図４】
2006139747.tif 000006
【図５】
2006139747.tif 000007
【図６】
2006139747.tif 000008
【図７】
2006139747.tif 000009
【図８】
2006139747.tif 000010
【図９】
2006139747.tif 000011
【図１０】
2006139747.tif 000012
【図１１】
2006139747.tif 000013
【図１２】
2006139747.tif 000014
【図１３】
2006139747.tif 000015
【図１４】
2006139747.tif 000016
【図１５】
2006139747.tif 000017
【図１６】
2006139747.tif 000018
【図１７】
2006139747.tif 000019
【図１８】
2006139747.tif 000020
【図１９】
2006139747.tif 000021
【図２０】
2006139747.tif 000022
【図２１】
2006139747.tif 000023
【図２２】
2006139747.tif 000024
【図２３】
2006139747.tif 000025
【図２４】
2006139747.tif 000026
【図２５】
2006139747.tif 000027