サービス妨害攻撃に耐性を持つＳＳＬ／ＴＬＳ準拠システム、方法、サーバ、プログラムおよび記録媒体
【課題】ＳＳＬ／ＴＬＳプロトコルに準拠して相互認証を行う場合に、クライアント側に何らの変更を齎すことなく、ＳＳＬ／ＴＬＳプロトコルのサービス妨害攻撃への耐性を向上させる。
【解決手段】ＳＳＬ／ＴＬＳプロトコルに準拠して相互認証を行う場合に、サーバにおいて、鍵取得処理（ClientKeyExchange受信後のＲＳＡ復号化、ＤＨ離散対数演算など）を署名検証処理（CertificateVerify）が成功した後に行う。また、サーバにおいて、署名検証に成功するセッションが現われるまでの間、サーバセッション初期化処理で得られたデータを再利用してもよい。
【解決手段】ＳＳＬ／ＴＬＳプロトコルに準拠して相互認証を行う場合に、サーバにおいて、鍵取得処理（ClientKeyExchange受信後のＲＳＡ復号化、ＤＨ離散対数演算など）を署名検証処理（CertificateVerify）が成功した後に行う。また、サーバにおいて、署名検証に成功するセッションが現われるまでの間、サーバセッション初期化処理で得られたデータを再利用してもよい。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＳＳＬ／ＴＬＳプロトコルのサービス妨害攻撃への耐性を向上させる技術に関する。
【背景技術】
【０００２】
ＳＳＬ（Secure Sockets Layer）あるいはＴＬＳ（Transport Layer Security）は、通信内容を暗号化して通信を行うための通信手順（プロトコル）である。ＳＳＬ Ver3.0の技術仕様は、非特許文献１に公開されている。また、ＴＬＳ Ver1.1の技術仕様は、ＩＥＴＦ（Internet Engineering Task Force）によってRequest for Comments（ＲＦＣ）４３４６（非特許文献２）に公開されている。
【０００３】
図１に、ＴＬＳ Ver1.1が規定するハンドシェイクプロトコル（Handshake Protocol）のメッセージフロー（Message flow）のモデルを示す。ＳＳＬ Version 3.0でも同様のメッセージフローであるが、ここではＴＬＳ Ver1.1を例にしてその概要を説明する。詳しくは非特許文献２を参照されたい。
【０００４】
クライアントは、乱数生成などのセッション初期化処理（クライアントセッション初期化処理）を行い、サーバへClientHelloを送信する。ClientHelloには、クライアント乱数、セッションＩＤ、クライアントが使える暗号アルゴリズムの種類のリスト（CipherSuite）、圧縮方式の種類のリスト（CompressionMethod）などが含まれる。
【０００５】
サーバは、ClientHelloを受信すると、乱数生成などのセッション初期化処理（サーバセッション初期化処理）を行い、クライアントへServerHelloを送信する。ServerHelloには、サーバ乱数、セッションＩＤ、クライアントから送られたCipherSuiteの中からサーバが一つ選択した暗号アルゴリズム、クライアントから送られたCompressionMethodの中からサーバが一つ選択した圧縮方式などが含まれる。
【０００６】
サーバは、ServerHelloの送信に続いて、オプションとして、ServerCertificate、ServerKeyExchange、CertificateRequestをクライアントに送信することができる。ServerCertificateは、ＩＴＵ（International Telecommunication Union）が勧告したX.509v3の仕様に準拠したサーバの電子証明書である。ServerKeyExchangeは、クライアントがサーバとプリマスタシークレット（a premaster secret ; PMS）の交換を行うために十分な情報がServerCertificateに含まれていない場合に送られる情報であって、例えばＲＳＡ暗号アルゴリズムの場合にはサーバのＲＳＡ臨時鍵などが含まれる。CertificateRequestは、サーバからクライアントの証明書の提供を要求する情報であり、サーバが信頼する認証局のリストなどが含まれる。
【０００７】
サーバは、ServerHelloとオプションとして送信された一連のメッセージ（ServerCertificate、ServerKeyExchange、CertificateRequest）の終了をクライアントに知らせる情報（ServerHelloDone）をクライアントに送信する。
【０００８】
クライアントは、サーバからServerHelloDoneを受信すると、サーバからCertificateRequestを受信していた場合にのみ、ClientCertificateをサーバに送信する。ClientCertificateは、ServerCertificateと同じ仕様に準拠した電子証明書である。
【０００９】
クライアントは、サーバからServerHelloDoneを受信した直後、あるいは、ClientCertificateをサーバへ送信した直後、クライアントとサーバとの間のHelloメッセージの遣り取りで決められた暗号アルゴリズムに則り、ClientKeyExchangeをサーバに送信する。例えば鍵交換に使用する暗号アルゴリズムがＲＳＡの場合、プリマスタシークレット（ＰＭＳ）として生成した乱数がサーバの公開鍵でＲＳＡ暗号化されたプリマスタシークレットがClientKeyExchangeに含まれる。また、鍵交換に使用する暗号アルゴリズムがＤＨ（Diffie-Hellman）の場合、クライアントが生成した秘密情報（乱数）をサーバの公開情報を用いて暗号化して得られた暗号化情報がClientKeyExchangeに含まれる。
【００１０】
サーバは、クライアントからClientKeyExchangeを受信すると、クライアントとサーバとの間のHelloメッセージの遣り取りで決められた暗号アルゴリズムに則り、マスタシークレット（a master secret）を生成する。例えばＲＳＡの場合、暗号化されたプリマスタシークレットに対してＲＳＡ復号化を行ってプリマスタシークレットを復号し、このプリマスタシークレットを入力の一つとするハッシュ関数ＰＲＦ（システム共通の関数）の値を求めることでマスタシークレットを生成する。また、ＤＨの場合、サーバの秘密情報を用いて暗号化情報からプリマスタシークレットを生成し、このプリマスタシークレットを入力の一つとするハッシュ関数ＰＲＦの値を求めることでマスタシークレットを生成する。
【００１１】
一方、クライアントも、プリマスタシークレットからマスタシークレットを生成する。例えばＲＳＡの場合、クライアントが生成したプリマスタシークレットを入力の一つとするハッシュ関数ＰＲＦの値を求めることでマスタシークレットを生成する。また、ＤＨの場合、クライアントの秘密情報を用いてサーバの公開情報からプリマスタシークレットを生成し、このプリマスタシークレットを入力の一つとするハッシュ関数ＰＲＦの値を求めることでマスタシークレットを生成する。クライアントとサーバで生成されたマスタシークレットは共通の値である。
【００１２】
クライアントは、ClientKeyExchangeの送信に続いて、オプションとして、CertificateVerifyをサーバに送信する。これは、クライアントがClientCertificateをサーバへ送信した場合に行われる。CertificateVerifyには、これまでのハンドシェイクメッセージ（handshake messages）のハッシュ値をクライアントの秘密鍵で暗号化して得られた署名が含まれる。
【００１３】
サーバは、クライアントからCertificateVerifyを受信すると、ClientCertificateから取り出したクライアントの公開鍵を使ってCertificateVerifyに含まれる署名を復号することでハッシュ値を得て、このハッシュ値と、これまでのハンドシェイクメッセージ（handshake messages）のハッシュ値とを比較して、クライアントの署名を検証する（クライアント認証）。
【００１４】
クライアントは、CertificateVerifyの送信に続いて、ChangeCipherSpecをサーバに送信する。ChangeCipherSpecは、クライアントとサーバの双方で決定した暗号アルゴリズムで通信を行うことの宣言である。さらに、クライアントは、ChangeCipherSpecの送信に続いて、Finishedをサーバに送信する。Finishedは、サーバとの一連の遣り取りによって暗号通信が可能な状態になったことを知らせる情報である。一方、サーバも、ChangeCipherSpecとFinishedをクライアントに送信する。
【００１５】
これら一連の処理が済むと、クライアントとサーバとの間で暗号化されたデータ（Application Data）を相互に通信できる（暗号通信処理）。
【００１６】
図１に示したメッセージフローモデルにおいて、暗号アルゴリズムをＲＳＡとした場合、ＤＨとした場合、ＤＨＥ（Diffie-Hellman Ephemeral）とした場合のそれぞれの具体的なメッセージフローをそれぞれ図２、図３、図４に示す。これらの詳細は非特許文献２に公開されているから詳細な説明を省略する。
【００１７】
上述の各手順の先後は非特許文献２に規定されている。例えば、CertificateVerifyについては、"When this message will be sent: This message is used to provide explicit verification of a client certificate. This message is only sent following a client certificate that has signing capability (i.e., all certificates except those containing fixed Diffie-Hellman parameters). When sent, it MUST immediately follow the client key exchange message."と規定されている。
【００１８】
このような規定に呼応して、サーバでは、クライアントからClientKeyExchangeを受信すると、少なくとも、プリマスタシークレットのＲＳＡ復号化（暗号アルゴリズムがＲＳＡの場合）や離散対数演算による暗号化情報からのプリマスタシークレット生成（暗号アルゴリズムがＤＨの場合）などの鍵取得処理を行ってから、クライアント認証（署名検証）を行っている。
【非特許文献１】The SSL Protocol Version 3.0、[平成２０年２月２１日検索]、インターネット〈http://wp.netscape.com/eng/ssl3/〉
【非特許文献２】The Transport Layer Security (TLS) Protocol Version 1.1、[平成２０年２月２１日検索]、インターネット〈http://tools.ietf.org/html/rfc4346〉
【発明の開示】
【発明が解決しようとする課題】
【００１９】
このようなＳＳＬ／ＴＬＳプロトコルは、サービス妨害（ＤｏＳ：Denial of Services）攻撃に対する耐性が低いという問題がある。
【００２０】
サービス妨害攻撃の一手法として、攻撃者が大量のリクエストをサーバに送信することによってサービス提供を妨害する攻撃手法がある。
【００２１】
ここでサービス妨害攻撃に対する耐性（以下、サービス妨害攻撃耐性とも云う。）は、サーバ側の処理負荷とクライアント側の処理負荷の比、つまり（サーバ側の処理負荷）／（クライアント側の処理負荷）で定義される。この値が大きいほど耐性が低いことになる。
【００２２】
従来、ＳＳＬ／ＴＬＳ相互認証時では、クライアント側の処理負荷は大きく分けて、クライアントセッション初期化処理（ClientHelloでのクライアント乱数生成など）、鍵交換処理（ClientKeyExchangeでの乱数生成、ＲＳＡ暗号化、ＤＨ離散対数演算など）、署名生成処理（CertificateVerify）であり、サーバ側の処理負荷は大きく分けて、サーバセッション初期化処理（ServerHelloでのサーバ乱数生成、ＤＨＥ一時鍵生成など）、鍵取得処理（ClientKeyExchange受信後のＲＳＡ復号化、ＤＨ離散対数演算など）、署名検証処理（CertificateVerify）である。
【００２３】
このとき、攻撃者クライアントが正規のクライアント証明書を有していないにも関わらず乱数生成に換えて固定値を用いるとすると、攻撃者クライアント側の処理負荷は正規の処理負荷よりも低減するが（理由：乱数生成処理を省略できる。）、サーバ側の処理負荷は正規の処理負荷と変わらないため（理由：クライアント認証（署名検証）に失敗するにも係らず、ＲＳＡ復号化やクライアント認証（署名検証）を実行する。）、サーバ側の処理負荷が攻撃者クライアント側の処理負荷よりも相対的に大きくなり、サービス妨害攻撃耐性は低くなる。
【００２４】
また、攻撃者クライアントが上記固定値を使い回して同一サーバへリクエストを繰り返し送信すると、サーバの処理負荷は、攻撃者クライアントの処理負荷に比して累積的に増大し、結果、サービス妨害攻撃耐性は著しく低くなる。
【００２５】
このような問題を解決するために、ＳＳＬ／ＴＬＳプロトコルの仕様を変更したプロトコルが提案されている。
Kemal BICAKCI, Bruno Crispo and Andrew S. Tanenbaum, "Reverse SSL: Improved Server Performance and DoS Resistance for SSL Handshakes", [平成２０年２月２１日検索], インターネット〈http://eprint.iacr.org/2006/212.pdf〉
【００２６】
しかし、このようなプロトコルを実装する場合には、現行のクライアント側のプログラムを変更する必要があるため、システム変更のコストが高いという問題がある（現在普及しているクライアント数はサーバ数よりも圧倒的に多いため、クライアント側のプログラム変更のコストは多大である。）。
【００２７】
そこで本発明の目的は、ＳＳＬ／ＴＬＳプロトコルに準拠して相互認証を行う場合に、クライアント側に何らの変更を齎すことなく、ＳＳＬ／ＴＬＳプロトコルのサービス妨害攻撃への耐性を向上させることである。
【課題を解決するための手段】
【００２８】
本発明では、ＳＳＬ／ＴＬＳプロトコルに準拠して相互認証を行う場合に、サーバにおいて、鍵取得処理（ClientKeyExchange受信後のＲＳＡ復号化、ＤＨ離散対数演算など）を署名検証処理（CertificateVerify）が成功した後に行う。現行のＳＳＬ／ＴＬＳプロトコルでは、クライアント側でClientKeyExchangeがCertificateVerifyに先行することが規定されているが、サーバ側でClientKeyExchangeを受信した後のＲＳＡ復号化、ＤＨ離散対数演算などを署名検証処理に先行させることは規定されていない。
【００２９】
また、サーバにおいて、署名検証に成功するセッションが現われるまでの間、サーバセッション初期化処理で得られたデータを再利用してもよい。つまり、クライアントからの最初のリクエストに対してサーバセッション初期化処理を行うが、その後にクライアントからリクエストを繰り返し受信しても、署名検証に成功するセッションが現われない限り、サーバセッション初期化処理を行わず、前記サーバセッション初期化処理で得られたデータを再利用してもよい。
【００３０】
また、本発明のサーバとしてコンピュータを機能させるプログラムによって、コンピュータをサーバとして作動処理させることができる。そして、このようなプログラムを記録した、コンピュータによって読み取り可能なプログラム記録媒体によって、他のコンピュータをサーバとして機能させることや、プログラムを流通させることなどが可能になる。
【発明の効果】
【００３１】
本発明によれば、ＳＳＬ／ＴＬＳプロトコルに準拠して相互認証を行う場合に、サーバにおいて署名検証（クライアント認証）に成功した後に鍵取得処理を行うため、攻撃者クライアントから大量のリクエストを受けてもリクエスト毎に鍵取得処理を行うことがない。よって、この処理負荷の低減を受けて従来よりも（サーバ側の処理負荷）／（クライアント側の処理負荷）が小さくなる。即ち、ＳＳＬ／ＴＬＳ相互認証時にこのプロトコルのサービス妨害攻撃耐性が向上する。また、サーバにおいて、署名検証に成功するセッションが現われるまでの間、サーバセッション初期化処理で得られたデータを再利用することで、リクエスト毎に行っていたサーバセッション初期化処理の負荷も低減できるから、一層、サービス妨害攻撃耐性が向上する。そして、本発明ではクライアント側には何らプロトコルの変更を齎さないから、現行のＳＳＬ／ＴＬＳプロトコルを採用して普及している現在の通信システムにおいてサーバのプログラム変更だけで本発明を実装できるという利点がある。
【発明を実施するための最良の形態】
【００３２】
《第１実施形態》
図面を参照して、本発明の第１実施形態を説明する。
第１実施形態でサーバ１００は、後述する構成を除き、従来的な相互認証ＳＳＬ／ＴＬＳプロトコルを処理するために必要な機能構成を備えている。つまり、後述する構成を除き、サーバ１００は、サーバセッション初期化処理、ServerHello、ServerCertificate、ServerKeyExchange、CertificateRequest、ServerHelloDone、ChangeCipherSpec、Finishedの送信処理およびClientHello、ClientCertificate、ClinetKeyExchange、CertificateVerify、ChangeCipherSpec、Finishedの受信処理、鍵取得処理、署名検証処理、暗号通信処理を実行するために必要な機能（サーバセッション初期化処理部、メッセージ送受信処理部、鍵取得処理部、署名検証処理部、暗号通信処理部）を有する（図５参照）。サーバ１００は中央処理装置、記憶装置、送受信装置などのハードウェアを備えたコンピュータで実現され、サーバ１００が発揮する機能構成部は所望の機能を発現するように記述されたプログラムを中央処理装置が解釈・実行することで実現される。
【００３３】
クライアント９００は、中央処理装置、記憶装置、送受信装置などのハードウェアを備えたコンピュータで実現され、クライアント９００が発揮する機能構成部は所望の機能を発現するように記述されたプログラムを中央処理装置が解釈・実行することで実現される。ただし、本発明の特徴の一つは、現行のＳＳＬ／ＴＬＳプロトコルを前提としてクライアントに何らの影響を与えないことであるから、クライアント９００は従前のとおりのハードウェア構成／ソフトウェア構成でよく、本明細書ではクライアント９００の詳細に立ち入らない。
【００３４】
また、第１実施形態において、サーバ１００とクライアント９００は相互通信可能に構成されており、この構成の詳細は、現行のＳＳＬ／ＴＬＳプロトコルを実施するシステム構成と同じである。
【００３５】
サーバ１００は、これが第１制御部１０１を備える構成である点で、従来構成のサーバと異なる（図５参照）。従来構成のサーバの制御部は、クライアント９００からClientKeyExchangeを受信した後、少なくとも、プリマスタシークレットのＲＳＡ復号化（暗号アルゴリズムがＲＳＡの場合）や離散対数演算による暗号化情報からのプリマスタシークレット生成（暗号アルゴリズムがＤＨの場合）などの鍵取得処理を実行するように鍵取得処理部を制御し、続いて、署名検証処理（クライアント認証）を実行するように署名検証処理部を制御していた。
【００３６】
このような従来構成に比して、サーバ１００の第１制御部１０１は、クライアント９００からClientKeyExchangeを受信した後、ClientKeyExchangeを記憶装置に記憶する制御を行い、次に、クライアント９００からClientVerifyの受信を待って署名検証処理（クライアント認証）を実行するように署名検証処理部を制御し、次いで、署名検証（クライアント認証）に成功した場合に、記憶装置に記憶されたClientKeyExchangeを用いて上記鍵取得処理を実行するように鍵取得処理部を制御する。署名検証に失敗した場合は、ＳＳＬ／ＴＬＳの仕様に準拠してAlert等がクライアントに通知される。
【００３７】
つまり、従来のプロトコルは、サーバがClientKeyExchangeを受信した後、
ステップ１：少なくとも、プリマスタシークレットのＲＳＡ復号化（暗号アルゴリズムがＲＳＡの場合）や離散対数演算による暗号化情報からのプリマスタシークレット生成（暗号アルゴリズムがＤＨの場合）などの鍵取得処理を実行する、
ステップ２：クライアント９００からClientVerifyを受信する、
ステップ３：署名検証（クライアント認証）を行う、
という手順で処理を行っていた。
これに対して第１実施形態では、サーバがClientKeyExchangeを受信した後、
ステップＳ１：クライアント９００から受信したClientKeyExchangeを記憶装置に記憶する、
ステップＳ２：クライアント９００からClientVerifyの受信を待って署名検証（クライアント認証）を実行する、
ステップＳ３：署名検証（クライアント認証）に成功した場合に、記憶装置に記憶されたClientKeyExchangeを用いて、少なくとも、プリマスタシークレットのＲＳＡ復号化（暗号アルゴリズムがＲＳＡの場合）や離散対数演算による暗号化情報からのプリマスタシークレット生成（暗号アルゴリズムがＤＨの場合）などの鍵取得処理を実行する、
という手順で処理を行う（図６参照）。サーバ１００での鍵取得処理は、サーバからChangeCipherSpecまたはFinishedがクライアント９００へ送信されるまでの間に行われればよい。この主旨で、図６では鍵取得処理をChangeCipherSpecの送信前に行っている場合を例示している。なお、上記ステップＳ１の処理よりも前の処理手順は現行ＳＳＬ／ＴＬＳプロトコルに準拠し、ステップＳ３の処理よりも後の処理手順も現行ＳＳＬ／ＴＬＳプロトコルに準拠する。
【００３８】
このように、署名検証（クライアント認証）に成功するまで鍵取得処理を行わないから、従来のサーバの処理負荷に比して第１実施形態のサーバ１００の処理負荷は低減しており、この効果は、正規のクライアント証明書を持たない攻撃者クライアントが大量のリクエストをサーバ１００に送信してきた場合に顕著である。つまり、サーバ１００のサービス妨害攻撃耐性は従来のサーバのそれに比べて向上している。
【００３９】
なお、本発明ではクライアント−サーバ間の相互認証を前提にしており、現行ＳＳＬ／ＴＬＳプロトコルではオプションとされるCertificateRequest、ClientCertificate、CertificateVerifyのクライアント−サーバ間送受信が必須であることに注意しなければならない。
【００４０】
図７に、署名生成および署名検証の各処理の負荷を示す。暗号アルゴリズムがＤＳＡの場合は両処理に大きな差異がないが、ＲＳＡの場合は両処理に顕著な差異が認められ、署名検証の方が署名生成よりも鍵長にもよるが１０倍程度高速である（図７点線枠囲み部参照）。よって、相互認証の場合には、署名検証を行うサーバ１００よりも署名生成を行うクライアント９００の方が大きな処理負荷を負担するから、（サーバ側の処理負荷）／（クライアント側の処理負荷）が小さくなり、サービス妨害攻撃耐性が向上する。
【００４１】
なお、サーバ１００の処理が複数のクライアントに対して並列処理を行う場合、並列処理を行うスレッド（thread）ごとに上記手順の処理を行う。
【００４２】
《第２実施形態》
第２実施形態は、第１実施形態を基礎として、署名検証に成功するセッションが現われるまでの間、サーバセッション初期化処理で得られたデータを再利用する実施形態である（図８参照）。
【００４３】
サーバ１００は、サーバ１００の記憶装置にサーバセッション初期化処理で得られたデータを記憶する領域（以下、記憶領域という。）を確保している。また、サーバ１００は第２制御部１０２を有している。サーバ１００の第２制御部１０２は、クライアント９００からClientHelloを受信すると、記憶領域にサーバセッション初期化処理で得られたデータが記憶されているか否かを確認する。記憶領域にサーバセッション初期化処理で得られたデータが記憶されていない場合には、第２制御部１０２は、サーバセッション初期化処理を行うようにサーバセッション初期化処理部を制御し、記憶領域にサーバセッション初期化処理で得られたデータが記憶されている場合には、第２制御部１０２は、サーバセッション初期化処理を行わないようにサーバセッション初期化処理部を制御する（図８の符号Ｓ４参照）。
【００４４】
そして、現行ＳＳＬ／ＴＬＳプロトコルに準拠した手順が実行されてサーバがClientKeyExchangeを受信すると第１実施形態で説明した手順が実行される。このとき、署名検証処理にて署名検証に成功すると、第１制御部１０１は記憶領域からサーバセッション初期化処理で得られたデータを消去する（図８の符号Ｓ２ａ参照）。署名検証に失敗した場合は、第１制御部１０１は記憶領域からサーバセッション初期化処理で得られたデータを消去せず、記憶領域に記憶されたデータは維持される。
【００４５】
このため、署名検証に成功するセッションが現われるまでの間、ひとたび記憶領域に記憶されたサーバセッション初期化処理で得られたデータが再利用されることになる。
【００４６】
《第３実施形態》
第３実施形態は、第１実施形態を前提として、例えば中継装置（以下、プロキシサーバという。）を介してＳＳＬ−ＶＰＮ（Secure Socket Layer Virtual Private Naetwork）に拡張対応する実施形態である（図９参照）。
【００４７】
第１実施形態のサーバ１００は、第３実施形態ではプロキシサーバ２００に対応している。但し、サーバセッション初期化処理をプロキシサーバ２００で行うのではなく、外部サーバ３００に委託して行っている。つまり、プロキシサーバ２００は、クライアント９００からClientHelloを受信すると、サーバセッション初期化処理を要求する情報（以下、初期化処理要求情報という。）を外部サーバ３００に送信し（図９の符号Ｓ５参照）、外部サーバ３００のセッション初期化処理部はサーバセッション初期化処理を行い、この処理で得られたデータをプロキシサーバ２００に送信する（図９の符号Ｓ６参照）。プロキシサーバ２００は、外部サーバ３００で生成されたデータを受信すると現行のＳＳＬ／ＴＬＳプロトコルに準拠して、このデータを含むServerHelloをクライアント９００に送信する。
【００４８】
第３実施形態においても、第１実施形態ないし第２実施形態のとおり、署名検証処理で署名検証に成功した後に鍵取得処理を行う。
【００４９】
署名検証に成功するセッションが現われるまでの間、ひとたび記憶領域に記憶されたサーバセッション初期化処理で得られたデータを再利用することは、プロキシサーバ２００に替えて外部サーバ３００によって行われる。
具体的には、プロキシサーバ２００は第３制御部１０３を有しており、第３制御部１０３は、クライアント９００からClientHelloを受信すると、プロキシサーバ２００の記憶領域に外部サーバ３００でのサーバセッション初期化処理で得られたデータが記憶されているか否かを確認する。プロキシサーバ２００の記憶領域に前記データが記憶されていない場合には、第３制御部１０３は、外部サーバ３００に対してサーバセッション初期化処理を要求する初期化処理要求情報（この情報には例えばClientHelloを含めることができる。）を送信するように制御を行い、プロキシサーバ２００の記憶領域に前記データが記憶されている場合には、第３制御部１０３は、外部サーバ３００に対して初期化処理要求情報を送信しないように制御を行う。この結果、第２実施形態と同様の処理がプロキシサーバ２００で実現する。
【００５０】
この第３実施形態は、出願済み未公開の特願２００７−８９９０６に開示された共通鍵設定システムおけるプロトコルとしても好適である。
【００５１】
以上の実施形態の他、本発明は上述の実施形態に限定されるものではなく、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。
【００５２】
また、上記サーバ１００またはプロキシサーバ２００における処理機能をコンピュータによって実現する場合、サーバ１００またはプロキシサーバ２００が有すべき機能の処理内容はプログラムによって記述される。そして、このプログラムをコンピュータで実行することにより、上記サーバ１００またはプロキシサーバ２００における処理機能がコンピュータ上で実現される。
【００５３】
この処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、例えば、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリ等どのようなものでもよい。具体的には、例えば、磁気記録装置として、ハードディスク装置、フレキシブルディスク、磁気テープ等を、光ディスクとして、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ（Random Access Memory）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）等を、光磁気記録媒体として、ＭＯ（Magneto-Optical disc）等を、半導体メモリとしてＥＥＰ−ＲＯＭ（Electronically Erasable and Programmable-Read Only Memory）等を用いることができる。
【００５４】
また、このプログラムの流通は、例えば、そのプログラムを記録したＤＶＤ、ＣＤ−ＲＯＭ等の可搬型記録媒体を販売、譲渡、貸与等することによって行う。さらに、このプログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することにより、このプログラムを流通させる構成としてもよい。
【００５５】
このようなプログラムを実行するコンピュータは、例えば、まず、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、一旦、自己の記憶装置に格納する。そして、処理の実行時、このコンピュータは、自己の記録媒体に格納されたプログラムを読み取り、読み取ったプログラムに従った処理を実行する。また、このプログラムの別の実行形態として、コンピュータが可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することとしてもよく、さらに、このコンピュータにサーバコンピュータからプログラムが転送されるたびに、逐次、受け取ったプログラムに従った処理を実行することとしてもよい。また、サーバコンピュータから、このコンピュータへのプログラムの転送は行わず、その実行指示と結果取得のみによって処理機能を実現する、いわゆるＡＳＰ（Application Service Provider）型のサービスによって、上述の処理を実行する構成としてもよい。なお、本形態におけるプログラムには、電子計算機による処理の用に供する情報であってプログラムに準ずるもの（コンピュータに対する直接の指令ではないがコンピュータの処理を規定する性質を有するデータ等）を含むものとする。
【００５６】
また、この形態では、コンピュータ上で所定のプログラムを実行させることにより、サーバ１００またはプロキシサーバ２００を構成することとしたが、これらの処理内容の少なくとも一部をハードウェア的に実現することとしてもよい。
【図面の簡単な説明】
【００５７】
【図１】従来のＳＳＬ／ＴＬＳハンドシェイクプロトコルのメッセージフローモデル。
【図２】図１に示すメッセージフローモデルにおいて暗号アルゴリズムがＲＳＡの場合のメッセージフロー。
【図３】図１に示すメッセージフローモデルにおいて暗号アルゴリズムがＤＨの場合のメッセージフロー。
【図４】図１に示すメッセージフローモデルにおいて暗号アルゴリズムがＤＨＥの場合のメッセージフロー。
【図５】本発明のＳＳＬ／ＴＬＳ準拠システム。
【図６】第１実施形態のＳＳＬ／ＴＬＳ準拠方法のメッセージフロー（プロトコル）。
【図７】ＲＳＡ、ＤＳＡの各場合において署名生成および署名検証の各処理の負荷を示す図。
【図８】第２実施形態のＳＳＬ／ＴＬＳ準拠方法のメッセージフロー（プロトコル）。
【図９】第３実施形態のＳＳＬ／ＴＬＳ準拠方法のメッセージフロー（プロトコル）。
【技術分野】
【０００１】
本発明は、ＳＳＬ／ＴＬＳプロトコルのサービス妨害攻撃への耐性を向上させる技術に関する。
【背景技術】
【０００２】
ＳＳＬ（Secure Sockets Layer）あるいはＴＬＳ（Transport Layer Security）は、通信内容を暗号化して通信を行うための通信手順（プロトコル）である。ＳＳＬ Ver3.0の技術仕様は、非特許文献１に公開されている。また、ＴＬＳ Ver1.1の技術仕様は、ＩＥＴＦ（Internet Engineering Task Force）によってRequest for Comments（ＲＦＣ）４３４６（非特許文献２）に公開されている。
【０００３】
図１に、ＴＬＳ Ver1.1が規定するハンドシェイクプロトコル（Handshake Protocol）のメッセージフロー（Message flow）のモデルを示す。ＳＳＬ Version 3.0でも同様のメッセージフローであるが、ここではＴＬＳ Ver1.1を例にしてその概要を説明する。詳しくは非特許文献２を参照されたい。
【０００４】
クライアントは、乱数生成などのセッション初期化処理（クライアントセッション初期化処理）を行い、サーバへClientHelloを送信する。ClientHelloには、クライアント乱数、セッションＩＤ、クライアントが使える暗号アルゴリズムの種類のリスト（CipherSuite）、圧縮方式の種類のリスト（CompressionMethod）などが含まれる。
【０００５】
サーバは、ClientHelloを受信すると、乱数生成などのセッション初期化処理（サーバセッション初期化処理）を行い、クライアントへServerHelloを送信する。ServerHelloには、サーバ乱数、セッションＩＤ、クライアントから送られたCipherSuiteの中からサーバが一つ選択した暗号アルゴリズム、クライアントから送られたCompressionMethodの中からサーバが一つ選択した圧縮方式などが含まれる。
【０００６】
サーバは、ServerHelloの送信に続いて、オプションとして、ServerCertificate、ServerKeyExchange、CertificateRequestをクライアントに送信することができる。ServerCertificateは、ＩＴＵ（International Telecommunication Union）が勧告したX.509v3の仕様に準拠したサーバの電子証明書である。ServerKeyExchangeは、クライアントがサーバとプリマスタシークレット（a premaster secret ; PMS）の交換を行うために十分な情報がServerCertificateに含まれていない場合に送られる情報であって、例えばＲＳＡ暗号アルゴリズムの場合にはサーバのＲＳＡ臨時鍵などが含まれる。CertificateRequestは、サーバからクライアントの証明書の提供を要求する情報であり、サーバが信頼する認証局のリストなどが含まれる。
【０００７】
サーバは、ServerHelloとオプションとして送信された一連のメッセージ（ServerCertificate、ServerKeyExchange、CertificateRequest）の終了をクライアントに知らせる情報（ServerHelloDone）をクライアントに送信する。
【０００８】
クライアントは、サーバからServerHelloDoneを受信すると、サーバからCertificateRequestを受信していた場合にのみ、ClientCertificateをサーバに送信する。ClientCertificateは、ServerCertificateと同じ仕様に準拠した電子証明書である。
【０００９】
クライアントは、サーバからServerHelloDoneを受信した直後、あるいは、ClientCertificateをサーバへ送信した直後、クライアントとサーバとの間のHelloメッセージの遣り取りで決められた暗号アルゴリズムに則り、ClientKeyExchangeをサーバに送信する。例えば鍵交換に使用する暗号アルゴリズムがＲＳＡの場合、プリマスタシークレット（ＰＭＳ）として生成した乱数がサーバの公開鍵でＲＳＡ暗号化されたプリマスタシークレットがClientKeyExchangeに含まれる。また、鍵交換に使用する暗号アルゴリズムがＤＨ（Diffie-Hellman）の場合、クライアントが生成した秘密情報（乱数）をサーバの公開情報を用いて暗号化して得られた暗号化情報がClientKeyExchangeに含まれる。
【００１０】
サーバは、クライアントからClientKeyExchangeを受信すると、クライアントとサーバとの間のHelloメッセージの遣り取りで決められた暗号アルゴリズムに則り、マスタシークレット（a master secret）を生成する。例えばＲＳＡの場合、暗号化されたプリマスタシークレットに対してＲＳＡ復号化を行ってプリマスタシークレットを復号し、このプリマスタシークレットを入力の一つとするハッシュ関数ＰＲＦ（システム共通の関数）の値を求めることでマスタシークレットを生成する。また、ＤＨの場合、サーバの秘密情報を用いて暗号化情報からプリマスタシークレットを生成し、このプリマスタシークレットを入力の一つとするハッシュ関数ＰＲＦの値を求めることでマスタシークレットを生成する。
【００１１】
一方、クライアントも、プリマスタシークレットからマスタシークレットを生成する。例えばＲＳＡの場合、クライアントが生成したプリマスタシークレットを入力の一つとするハッシュ関数ＰＲＦの値を求めることでマスタシークレットを生成する。また、ＤＨの場合、クライアントの秘密情報を用いてサーバの公開情報からプリマスタシークレットを生成し、このプリマスタシークレットを入力の一つとするハッシュ関数ＰＲＦの値を求めることでマスタシークレットを生成する。クライアントとサーバで生成されたマスタシークレットは共通の値である。
【００１２】
クライアントは、ClientKeyExchangeの送信に続いて、オプションとして、CertificateVerifyをサーバに送信する。これは、クライアントがClientCertificateをサーバへ送信した場合に行われる。CertificateVerifyには、これまでのハンドシェイクメッセージ（handshake messages）のハッシュ値をクライアントの秘密鍵で暗号化して得られた署名が含まれる。
【００１３】
サーバは、クライアントからCertificateVerifyを受信すると、ClientCertificateから取り出したクライアントの公開鍵を使ってCertificateVerifyに含まれる署名を復号することでハッシュ値を得て、このハッシュ値と、これまでのハンドシェイクメッセージ（handshake messages）のハッシュ値とを比較して、クライアントの署名を検証する（クライアント認証）。
【００１４】
クライアントは、CertificateVerifyの送信に続いて、ChangeCipherSpecをサーバに送信する。ChangeCipherSpecは、クライアントとサーバの双方で決定した暗号アルゴリズムで通信を行うことの宣言である。さらに、クライアントは、ChangeCipherSpecの送信に続いて、Finishedをサーバに送信する。Finishedは、サーバとの一連の遣り取りによって暗号通信が可能な状態になったことを知らせる情報である。一方、サーバも、ChangeCipherSpecとFinishedをクライアントに送信する。
【００１５】
これら一連の処理が済むと、クライアントとサーバとの間で暗号化されたデータ（Application Data）を相互に通信できる（暗号通信処理）。
【００１６】
図１に示したメッセージフローモデルにおいて、暗号アルゴリズムをＲＳＡとした場合、ＤＨとした場合、ＤＨＥ（Diffie-Hellman Ephemeral）とした場合のそれぞれの具体的なメッセージフローをそれぞれ図２、図３、図４に示す。これらの詳細は非特許文献２に公開されているから詳細な説明を省略する。
【００１７】
上述の各手順の先後は非特許文献２に規定されている。例えば、CertificateVerifyについては、"When this message will be sent: This message is used to provide explicit verification of a client certificate. This message is only sent following a client certificate that has signing capability (i.e., all certificates except those containing fixed Diffie-Hellman parameters). When sent, it MUST immediately follow the client key exchange message."と規定されている。
【００１８】
このような規定に呼応して、サーバでは、クライアントからClientKeyExchangeを受信すると、少なくとも、プリマスタシークレットのＲＳＡ復号化（暗号アルゴリズムがＲＳＡの場合）や離散対数演算による暗号化情報からのプリマスタシークレット生成（暗号アルゴリズムがＤＨの場合）などの鍵取得処理を行ってから、クライアント認証（署名検証）を行っている。
【非特許文献１】The SSL Protocol Version 3.0、[平成２０年２月２１日検索]、インターネット〈http://wp.netscape.com/eng/ssl3/〉
【非特許文献２】The Transport Layer Security (TLS) Protocol Version 1.1、[平成２０年２月２１日検索]、インターネット〈http://tools.ietf.org/html/rfc4346〉
【発明の開示】
【発明が解決しようとする課題】
【００１９】
このようなＳＳＬ／ＴＬＳプロトコルは、サービス妨害（ＤｏＳ：Denial of Services）攻撃に対する耐性が低いという問題がある。
【００２０】
サービス妨害攻撃の一手法として、攻撃者が大量のリクエストをサーバに送信することによってサービス提供を妨害する攻撃手法がある。
【００２１】
ここでサービス妨害攻撃に対する耐性（以下、サービス妨害攻撃耐性とも云う。）は、サーバ側の処理負荷とクライアント側の処理負荷の比、つまり（サーバ側の処理負荷）／（クライアント側の処理負荷）で定義される。この値が大きいほど耐性が低いことになる。
【００２２】
従来、ＳＳＬ／ＴＬＳ相互認証時では、クライアント側の処理負荷は大きく分けて、クライアントセッション初期化処理（ClientHelloでのクライアント乱数生成など）、鍵交換処理（ClientKeyExchangeでの乱数生成、ＲＳＡ暗号化、ＤＨ離散対数演算など）、署名生成処理（CertificateVerify）であり、サーバ側の処理負荷は大きく分けて、サーバセッション初期化処理（ServerHelloでのサーバ乱数生成、ＤＨＥ一時鍵生成など）、鍵取得処理（ClientKeyExchange受信後のＲＳＡ復号化、ＤＨ離散対数演算など）、署名検証処理（CertificateVerify）である。
【００２３】
このとき、攻撃者クライアントが正規のクライアント証明書を有していないにも関わらず乱数生成に換えて固定値を用いるとすると、攻撃者クライアント側の処理負荷は正規の処理負荷よりも低減するが（理由：乱数生成処理を省略できる。）、サーバ側の処理負荷は正規の処理負荷と変わらないため（理由：クライアント認証（署名検証）に失敗するにも係らず、ＲＳＡ復号化やクライアント認証（署名検証）を実行する。）、サーバ側の処理負荷が攻撃者クライアント側の処理負荷よりも相対的に大きくなり、サービス妨害攻撃耐性は低くなる。
【００２４】
また、攻撃者クライアントが上記固定値を使い回して同一サーバへリクエストを繰り返し送信すると、サーバの処理負荷は、攻撃者クライアントの処理負荷に比して累積的に増大し、結果、サービス妨害攻撃耐性は著しく低くなる。
【００２５】
このような問題を解決するために、ＳＳＬ／ＴＬＳプロトコルの仕様を変更したプロトコルが提案されている。
Kemal BICAKCI, Bruno Crispo and Andrew S. Tanenbaum, "Reverse SSL: Improved Server Performance and DoS Resistance for SSL Handshakes", [平成２０年２月２１日検索], インターネット〈http://eprint.iacr.org/2006/212.pdf〉
【００２６】
しかし、このようなプロトコルを実装する場合には、現行のクライアント側のプログラムを変更する必要があるため、システム変更のコストが高いという問題がある（現在普及しているクライアント数はサーバ数よりも圧倒的に多いため、クライアント側のプログラム変更のコストは多大である。）。
【００２７】
そこで本発明の目的は、ＳＳＬ／ＴＬＳプロトコルに準拠して相互認証を行う場合に、クライアント側に何らの変更を齎すことなく、ＳＳＬ／ＴＬＳプロトコルのサービス妨害攻撃への耐性を向上させることである。
【課題を解決するための手段】
【００２８】
本発明では、ＳＳＬ／ＴＬＳプロトコルに準拠して相互認証を行う場合に、サーバにおいて、鍵取得処理（ClientKeyExchange受信後のＲＳＡ復号化、ＤＨ離散対数演算など）を署名検証処理（CertificateVerify）が成功した後に行う。現行のＳＳＬ／ＴＬＳプロトコルでは、クライアント側でClientKeyExchangeがCertificateVerifyに先行することが規定されているが、サーバ側でClientKeyExchangeを受信した後のＲＳＡ復号化、ＤＨ離散対数演算などを署名検証処理に先行させることは規定されていない。
【００２９】
また、サーバにおいて、署名検証に成功するセッションが現われるまでの間、サーバセッション初期化処理で得られたデータを再利用してもよい。つまり、クライアントからの最初のリクエストに対してサーバセッション初期化処理を行うが、その後にクライアントからリクエストを繰り返し受信しても、署名検証に成功するセッションが現われない限り、サーバセッション初期化処理を行わず、前記サーバセッション初期化処理で得られたデータを再利用してもよい。
【００３０】
また、本発明のサーバとしてコンピュータを機能させるプログラムによって、コンピュータをサーバとして作動処理させることができる。そして、このようなプログラムを記録した、コンピュータによって読み取り可能なプログラム記録媒体によって、他のコンピュータをサーバとして機能させることや、プログラムを流通させることなどが可能になる。
【発明の効果】
【００３１】
本発明によれば、ＳＳＬ／ＴＬＳプロトコルに準拠して相互認証を行う場合に、サーバにおいて署名検証（クライアント認証）に成功した後に鍵取得処理を行うため、攻撃者クライアントから大量のリクエストを受けてもリクエスト毎に鍵取得処理を行うことがない。よって、この処理負荷の低減を受けて従来よりも（サーバ側の処理負荷）／（クライアント側の処理負荷）が小さくなる。即ち、ＳＳＬ／ＴＬＳ相互認証時にこのプロトコルのサービス妨害攻撃耐性が向上する。また、サーバにおいて、署名検証に成功するセッションが現われるまでの間、サーバセッション初期化処理で得られたデータを再利用することで、リクエスト毎に行っていたサーバセッション初期化処理の負荷も低減できるから、一層、サービス妨害攻撃耐性が向上する。そして、本発明ではクライアント側には何らプロトコルの変更を齎さないから、現行のＳＳＬ／ＴＬＳプロトコルを採用して普及している現在の通信システムにおいてサーバのプログラム変更だけで本発明を実装できるという利点がある。
【発明を実施するための最良の形態】
【００３２】
《第１実施形態》
図面を参照して、本発明の第１実施形態を説明する。
第１実施形態でサーバ１００は、後述する構成を除き、従来的な相互認証ＳＳＬ／ＴＬＳプロトコルを処理するために必要な機能構成を備えている。つまり、後述する構成を除き、サーバ１００は、サーバセッション初期化処理、ServerHello、ServerCertificate、ServerKeyExchange、CertificateRequest、ServerHelloDone、ChangeCipherSpec、Finishedの送信処理およびClientHello、ClientCertificate、ClinetKeyExchange、CertificateVerify、ChangeCipherSpec、Finishedの受信処理、鍵取得処理、署名検証処理、暗号通信処理を実行するために必要な機能（サーバセッション初期化処理部、メッセージ送受信処理部、鍵取得処理部、署名検証処理部、暗号通信処理部）を有する（図５参照）。サーバ１００は中央処理装置、記憶装置、送受信装置などのハードウェアを備えたコンピュータで実現され、サーバ１００が発揮する機能構成部は所望の機能を発現するように記述されたプログラムを中央処理装置が解釈・実行することで実現される。
【００３３】
クライアント９００は、中央処理装置、記憶装置、送受信装置などのハードウェアを備えたコンピュータで実現され、クライアント９００が発揮する機能構成部は所望の機能を発現するように記述されたプログラムを中央処理装置が解釈・実行することで実現される。ただし、本発明の特徴の一つは、現行のＳＳＬ／ＴＬＳプロトコルを前提としてクライアントに何らの影響を与えないことであるから、クライアント９００は従前のとおりのハードウェア構成／ソフトウェア構成でよく、本明細書ではクライアント９００の詳細に立ち入らない。
【００３４】
また、第１実施形態において、サーバ１００とクライアント９００は相互通信可能に構成されており、この構成の詳細は、現行のＳＳＬ／ＴＬＳプロトコルを実施するシステム構成と同じである。
【００３５】
サーバ１００は、これが第１制御部１０１を備える構成である点で、従来構成のサーバと異なる（図５参照）。従来構成のサーバの制御部は、クライアント９００からClientKeyExchangeを受信した後、少なくとも、プリマスタシークレットのＲＳＡ復号化（暗号アルゴリズムがＲＳＡの場合）や離散対数演算による暗号化情報からのプリマスタシークレット生成（暗号アルゴリズムがＤＨの場合）などの鍵取得処理を実行するように鍵取得処理部を制御し、続いて、署名検証処理（クライアント認証）を実行するように署名検証処理部を制御していた。
【００３６】
このような従来構成に比して、サーバ１００の第１制御部１０１は、クライアント９００からClientKeyExchangeを受信した後、ClientKeyExchangeを記憶装置に記憶する制御を行い、次に、クライアント９００からClientVerifyの受信を待って署名検証処理（クライアント認証）を実行するように署名検証処理部を制御し、次いで、署名検証（クライアント認証）に成功した場合に、記憶装置に記憶されたClientKeyExchangeを用いて上記鍵取得処理を実行するように鍵取得処理部を制御する。署名検証に失敗した場合は、ＳＳＬ／ＴＬＳの仕様に準拠してAlert等がクライアントに通知される。
【００３７】
つまり、従来のプロトコルは、サーバがClientKeyExchangeを受信した後、
ステップ１：少なくとも、プリマスタシークレットのＲＳＡ復号化（暗号アルゴリズムがＲＳＡの場合）や離散対数演算による暗号化情報からのプリマスタシークレット生成（暗号アルゴリズムがＤＨの場合）などの鍵取得処理を実行する、
ステップ２：クライアント９００からClientVerifyを受信する、
ステップ３：署名検証（クライアント認証）を行う、
という手順で処理を行っていた。
これに対して第１実施形態では、サーバがClientKeyExchangeを受信した後、
ステップＳ１：クライアント９００から受信したClientKeyExchangeを記憶装置に記憶する、
ステップＳ２：クライアント９００からClientVerifyの受信を待って署名検証（クライアント認証）を実行する、
ステップＳ３：署名検証（クライアント認証）に成功した場合に、記憶装置に記憶されたClientKeyExchangeを用いて、少なくとも、プリマスタシークレットのＲＳＡ復号化（暗号アルゴリズムがＲＳＡの場合）や離散対数演算による暗号化情報からのプリマスタシークレット生成（暗号アルゴリズムがＤＨの場合）などの鍵取得処理を実行する、
という手順で処理を行う（図６参照）。サーバ１００での鍵取得処理は、サーバからChangeCipherSpecまたはFinishedがクライアント９００へ送信されるまでの間に行われればよい。この主旨で、図６では鍵取得処理をChangeCipherSpecの送信前に行っている場合を例示している。なお、上記ステップＳ１の処理よりも前の処理手順は現行ＳＳＬ／ＴＬＳプロトコルに準拠し、ステップＳ３の処理よりも後の処理手順も現行ＳＳＬ／ＴＬＳプロトコルに準拠する。
【００３８】
このように、署名検証（クライアント認証）に成功するまで鍵取得処理を行わないから、従来のサーバの処理負荷に比して第１実施形態のサーバ１００の処理負荷は低減しており、この効果は、正規のクライアント証明書を持たない攻撃者クライアントが大量のリクエストをサーバ１００に送信してきた場合に顕著である。つまり、サーバ１００のサービス妨害攻撃耐性は従来のサーバのそれに比べて向上している。
【００３９】
なお、本発明ではクライアント−サーバ間の相互認証を前提にしており、現行ＳＳＬ／ＴＬＳプロトコルではオプションとされるCertificateRequest、ClientCertificate、CertificateVerifyのクライアント−サーバ間送受信が必須であることに注意しなければならない。
【００４０】
図７に、署名生成および署名検証の各処理の負荷を示す。暗号アルゴリズムがＤＳＡの場合は両処理に大きな差異がないが、ＲＳＡの場合は両処理に顕著な差異が認められ、署名検証の方が署名生成よりも鍵長にもよるが１０倍程度高速である（図７点線枠囲み部参照）。よって、相互認証の場合には、署名検証を行うサーバ１００よりも署名生成を行うクライアント９００の方が大きな処理負荷を負担するから、（サーバ側の処理負荷）／（クライアント側の処理負荷）が小さくなり、サービス妨害攻撃耐性が向上する。
【００４１】
なお、サーバ１００の処理が複数のクライアントに対して並列処理を行う場合、並列処理を行うスレッド（thread）ごとに上記手順の処理を行う。
【００４２】
《第２実施形態》
第２実施形態は、第１実施形態を基礎として、署名検証に成功するセッションが現われるまでの間、サーバセッション初期化処理で得られたデータを再利用する実施形態である（図８参照）。
【００４３】
サーバ１００は、サーバ１００の記憶装置にサーバセッション初期化処理で得られたデータを記憶する領域（以下、記憶領域という。）を確保している。また、サーバ１００は第２制御部１０２を有している。サーバ１００の第２制御部１０２は、クライアント９００からClientHelloを受信すると、記憶領域にサーバセッション初期化処理で得られたデータが記憶されているか否かを確認する。記憶領域にサーバセッション初期化処理で得られたデータが記憶されていない場合には、第２制御部１０２は、サーバセッション初期化処理を行うようにサーバセッション初期化処理部を制御し、記憶領域にサーバセッション初期化処理で得られたデータが記憶されている場合には、第２制御部１０２は、サーバセッション初期化処理を行わないようにサーバセッション初期化処理部を制御する（図８の符号Ｓ４参照）。
【００４４】
そして、現行ＳＳＬ／ＴＬＳプロトコルに準拠した手順が実行されてサーバがClientKeyExchangeを受信すると第１実施形態で説明した手順が実行される。このとき、署名検証処理にて署名検証に成功すると、第１制御部１０１は記憶領域からサーバセッション初期化処理で得られたデータを消去する（図８の符号Ｓ２ａ参照）。署名検証に失敗した場合は、第１制御部１０１は記憶領域からサーバセッション初期化処理で得られたデータを消去せず、記憶領域に記憶されたデータは維持される。
【００４５】
このため、署名検証に成功するセッションが現われるまでの間、ひとたび記憶領域に記憶されたサーバセッション初期化処理で得られたデータが再利用されることになる。
【００４６】
《第３実施形態》
第３実施形態は、第１実施形態を前提として、例えば中継装置（以下、プロキシサーバという。）を介してＳＳＬ−ＶＰＮ（Secure Socket Layer Virtual Private Naetwork）に拡張対応する実施形態である（図９参照）。
【００４７】
第１実施形態のサーバ１００は、第３実施形態ではプロキシサーバ２００に対応している。但し、サーバセッション初期化処理をプロキシサーバ２００で行うのではなく、外部サーバ３００に委託して行っている。つまり、プロキシサーバ２００は、クライアント９００からClientHelloを受信すると、サーバセッション初期化処理を要求する情報（以下、初期化処理要求情報という。）を外部サーバ３００に送信し（図９の符号Ｓ５参照）、外部サーバ３００のセッション初期化処理部はサーバセッション初期化処理を行い、この処理で得られたデータをプロキシサーバ２００に送信する（図９の符号Ｓ６参照）。プロキシサーバ２００は、外部サーバ３００で生成されたデータを受信すると現行のＳＳＬ／ＴＬＳプロトコルに準拠して、このデータを含むServerHelloをクライアント９００に送信する。
【００４８】
第３実施形態においても、第１実施形態ないし第２実施形態のとおり、署名検証処理で署名検証に成功した後に鍵取得処理を行う。
【００４９】
署名検証に成功するセッションが現われるまでの間、ひとたび記憶領域に記憶されたサーバセッション初期化処理で得られたデータを再利用することは、プロキシサーバ２００に替えて外部サーバ３００によって行われる。
具体的には、プロキシサーバ２００は第３制御部１０３を有しており、第３制御部１０３は、クライアント９００からClientHelloを受信すると、プロキシサーバ２００の記憶領域に外部サーバ３００でのサーバセッション初期化処理で得られたデータが記憶されているか否かを確認する。プロキシサーバ２００の記憶領域に前記データが記憶されていない場合には、第３制御部１０３は、外部サーバ３００に対してサーバセッション初期化処理を要求する初期化処理要求情報（この情報には例えばClientHelloを含めることができる。）を送信するように制御を行い、プロキシサーバ２００の記憶領域に前記データが記憶されている場合には、第３制御部１０３は、外部サーバ３００に対して初期化処理要求情報を送信しないように制御を行う。この結果、第２実施形態と同様の処理がプロキシサーバ２００で実現する。
【００５０】
この第３実施形態は、出願済み未公開の特願２００７−８９９０６に開示された共通鍵設定システムおけるプロトコルとしても好適である。
【００５１】
以上の実施形態の他、本発明は上述の実施形態に限定されるものではなく、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。
【００５２】
また、上記サーバ１００またはプロキシサーバ２００における処理機能をコンピュータによって実現する場合、サーバ１００またはプロキシサーバ２００が有すべき機能の処理内容はプログラムによって記述される。そして、このプログラムをコンピュータで実行することにより、上記サーバ１００またはプロキシサーバ２００における処理機能がコンピュータ上で実現される。
【００５３】
この処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、例えば、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリ等どのようなものでもよい。具体的には、例えば、磁気記録装置として、ハードディスク装置、フレキシブルディスク、磁気テープ等を、光ディスクとして、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ（Random Access Memory）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）等を、光磁気記録媒体として、ＭＯ（Magneto-Optical disc）等を、半導体メモリとしてＥＥＰ−ＲＯＭ（Electronically Erasable and Programmable-Read Only Memory）等を用いることができる。
【００５４】
また、このプログラムの流通は、例えば、そのプログラムを記録したＤＶＤ、ＣＤ−ＲＯＭ等の可搬型記録媒体を販売、譲渡、貸与等することによって行う。さらに、このプログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することにより、このプログラムを流通させる構成としてもよい。
【００５５】
このようなプログラムを実行するコンピュータは、例えば、まず、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、一旦、自己の記憶装置に格納する。そして、処理の実行時、このコンピュータは、自己の記録媒体に格納されたプログラムを読み取り、読み取ったプログラムに従った処理を実行する。また、このプログラムの別の実行形態として、コンピュータが可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することとしてもよく、さらに、このコンピュータにサーバコンピュータからプログラムが転送されるたびに、逐次、受け取ったプログラムに従った処理を実行することとしてもよい。また、サーバコンピュータから、このコンピュータへのプログラムの転送は行わず、その実行指示と結果取得のみによって処理機能を実現する、いわゆるＡＳＰ（Application Service Provider）型のサービスによって、上述の処理を実行する構成としてもよい。なお、本形態におけるプログラムには、電子計算機による処理の用に供する情報であってプログラムに準ずるもの（コンピュータに対する直接の指令ではないがコンピュータの処理を規定する性質を有するデータ等）を含むものとする。
【００５６】
また、この形態では、コンピュータ上で所定のプログラムを実行させることにより、サーバ１００またはプロキシサーバ２００を構成することとしたが、これらの処理内容の少なくとも一部をハードウェア的に実現することとしてもよい。
【図面の簡単な説明】
【００５７】
【図１】従来のＳＳＬ／ＴＬＳハンドシェイクプロトコルのメッセージフローモデル。
【図２】図１に示すメッセージフローモデルにおいて暗号アルゴリズムがＲＳＡの場合のメッセージフロー。
【図３】図１に示すメッセージフローモデルにおいて暗号アルゴリズムがＤＨの場合のメッセージフロー。
【図４】図１に示すメッセージフローモデルにおいて暗号アルゴリズムがＤＨＥの場合のメッセージフロー。
【図５】本発明のＳＳＬ／ＴＬＳ準拠システム。
【図６】第１実施形態のＳＳＬ／ＴＬＳ準拠方法のメッセージフロー（プロトコル）。
【図７】ＲＳＡ、ＤＳＡの各場合において署名生成および署名検証の各処理の負荷を示す図。
【図８】第２実施形態のＳＳＬ／ＴＬＳ準拠方法のメッセージフロー（プロトコル）。
【図９】第３実施形態のＳＳＬ／ＴＬＳ準拠方法のメッセージフロー（プロトコル）。
【特許請求の範囲】
【請求項１】
ＳＳＬ／ＴＬＳプロトコルに準拠して、サーバで少なくとも鍵取得処理、署名検証処理が行われ、サーバとクライアントの間で相互認証して暗号通信を行うＳＳＬ／ＴＬＳ準拠システムにおいて、
上記サーバが、
上記クライアントからClientKeyExchangeを受信した後、ClientKeyExchangeを上記サーバの記憶装置に記憶する制御を行い、上記クライアントからClientVerifyの受信を待って署名検証処理を実行するように制御し、次いで、署名検証に成功した場合に、上記記憶装置に記憶されたClientKeyExchangeを用いて鍵取得処理を実行するように制御する第１制御部を備えている
ことを特徴とするＳＳＬ／ＴＬＳ準拠システム。
【請求項２】
上記クライアントからClientHelloを受信すると、上記記憶装置に上記サーバのセッション初期化処理で得られたデータが記憶されているか否かを確認し、上記記憶装置に前記データが記憶されていない場合には、上記サーバのセッション初期化処理を行うように制御し、上記記憶装置に前記データが記憶されている場合には、上記サーバのセッション初期化処理を行わないように制御する第２制御部を上記サーバはさらに備え、
上記第１制御部は、署名検証に成功すると、上記記憶装置に記憶されている前記データを消去する処理を行う
ことを特徴とする請求項１に記載のＳＳＬ／ＴＬＳ準拠システム。
【請求項３】
セッション初期化処理を行う外部サーバをさらに備え、
上記クライアントからClientHelloを受信すると、上記記憶装置に上記外部サーバのセッション初期化処理で得られたデータが記憶されているか否かを確認し、前記データが記憶されていない場合には、上記外部サーバに対してセッション初期化処理を要求する情報（以下、初期化処理要求情報という。）を送信するように制御を行い、上記記憶装置に前記データが記憶されている場合には、上記外部サーバに対して初期化処理要求情報を送信しないように制御を行う第３制御部を上記サーバはさらに備えている
ことを特徴とする請求項１に記載のＳＳＬ／ＴＬＳ準拠システム。
【請求項４】
ＳＳＬ／ＴＬＳプロトコルに準拠して、サーバで少なくとも鍵取得処理、署名検証処理が行われ、サーバとクライアントの間で相互認証して暗号通信を行うＳＳＬ／ＴＬＳ準拠方法において、
上記サーバの第１制御部が、上記クライアントからClientKeyExchangeを受信した後、ClientKeyExchangeを上記サーバの記憶装置に記憶する制御を行う第１ステップと、
上記サーバの第１制御部が、上記クライアントからClientVerifyの受信を待って署名検証処理を実行するように制御する第２ステップと、
上記サーバの第１制御部が、署名検証に成功した場合に、上記記憶装置に記憶されたClientKeyExchangeを用いて鍵取得処理を実行するように制御する第３ステップを有する
ことを特徴とするＳＳＬ／ＴＬＳ準拠方法。
【請求項５】
上記サーバの第２制御部が、上記クライアントからClientHelloを受信すると、上記記憶装置に上記サーバのセッション初期化処理で得られたデータが記憶されているか否かを確認し、上記記憶装置に前記データが記憶されていない場合には、上記サーバのセッション初期化処理を行うように制御し、上記記憶装置に前記データが記憶されている場合には、上記サーバのセッション初期化処理を行わないように制御するセッション初期化制御ステップと、
上記サーバの第１制御部が、署名検証に成功すると、上記記憶装置に記憶されている前記データを消去する処理を行う第４ステップと
を有する
ことを特徴とする請求項４に記載のＳＳＬ／ＴＬＳ準拠方法。
【請求項６】
上記サーバの第３制御部が、上記クライアントからClientHelloを受信すると、上記記憶装置にセッション初期化処理を行う外部サーバのセッション初期化処理で得られたデータが記憶されているか否かを確認し、前記データが記憶されていない場合には、上記外部サーバに対してセッション初期化処理を要求する情報（以下、初期化処理要求情報という。）を送信するように制御を行い、上記記憶装置に前記データが記憶されている場合には、上記外部サーバに対して初期化処理要求情報を送信しないように制御を行うセッション初期化委託ステップと、
上記サーバの第１制御部が、署名検証に成功すると、上記記憶装置に記憶されている前記データを消去する処理を行う第４ステップと
を有する
ことを特徴とする請求項４に記載のＳＳＬ／ＴＬＳ準拠方法。
【請求項７】
ＳＳＬ／ＴＬＳプロトコルに準拠して、少なくとも鍵取得処理、署名検証処理が行われ、クライアントとの間で相互認証して暗号通信を行うＳＳＬ／ＴＬＳ準拠サーバにおいて、
上記サーバが、
上記クライアントからClientKeyExchangeを受信した後、ClientKeyExchangeを上記サーバの記憶装置に記憶する制御を行い、上記クライアントからClientVerifyの受信を待って署名検証処理を実行するように制御し、次いで、署名検証に成功した場合に、上記記憶装置に記憶されたClientKeyExchangeを用いて鍵取得処理を実行するように制御する第１制御部を備えている
ことを特徴とするＳＳＬ／ＴＬＳ準拠サーバ。
【請求項８】
上記クライアントからClientHelloを受信すると、上記記憶装置に上記セッション初期化処理で得られたデータが記憶されているか否かを確認し、上記記憶装置に上記セッション初期化処理で得られたデータが記憶されていない場合には、セッション初期化処理を行うように制御し、上記記憶装置に上記セッション初期化処理で得られたデータが記憶されている場合には、セッション初期化処理を行わないように制御する第２制御部をさらに備えている
ことを特徴とする請求項７に記載のＳＳＬ／ＴＬＳ準拠サーバ。
【請求項９】
上記クライアントからClientHelloを受信すると、上記記憶装置にセッション初期化処理を行う外部サーバのセッション初期化処理で得られたデータが記憶されているか否かを確認し、前記データが記憶されていない場合には、上記外部サーバに対してセッション初期化処理を要求する情報（以下、初期化処理要求情報という。）を送信するように制御を行い、上記記憶装置に前記データが記憶されている場合には、上記外部サーバに対して初期化処理要求情報を送信しないように制御を行う第３制御部をさらに備えている
ことを特徴とする請求項７に記載のＳＳＬ／ＴＬＳ準拠サーバ。
【請求項１０】
請求項７から請求項９のいずれかに記載されたＳＳＬ／ＴＬＳ準拠サーバとしてコンピュータを機能させるためのプログラム。
【請求項１１】
請求項１０に記載のプログラムを記録したコンピュータに読み取り可能な記録媒体。
【請求項１】
ＳＳＬ／ＴＬＳプロトコルに準拠して、サーバで少なくとも鍵取得処理、署名検証処理が行われ、サーバとクライアントの間で相互認証して暗号通信を行うＳＳＬ／ＴＬＳ準拠システムにおいて、
上記サーバが、
上記クライアントからClientKeyExchangeを受信した後、ClientKeyExchangeを上記サーバの記憶装置に記憶する制御を行い、上記クライアントからClientVerifyの受信を待って署名検証処理を実行するように制御し、次いで、署名検証に成功した場合に、上記記憶装置に記憶されたClientKeyExchangeを用いて鍵取得処理を実行するように制御する第１制御部を備えている
ことを特徴とするＳＳＬ／ＴＬＳ準拠システム。
【請求項２】
上記クライアントからClientHelloを受信すると、上記記憶装置に上記サーバのセッション初期化処理で得られたデータが記憶されているか否かを確認し、上記記憶装置に前記データが記憶されていない場合には、上記サーバのセッション初期化処理を行うように制御し、上記記憶装置に前記データが記憶されている場合には、上記サーバのセッション初期化処理を行わないように制御する第２制御部を上記サーバはさらに備え、
上記第１制御部は、署名検証に成功すると、上記記憶装置に記憶されている前記データを消去する処理を行う
ことを特徴とする請求項１に記載のＳＳＬ／ＴＬＳ準拠システム。
【請求項３】
セッション初期化処理を行う外部サーバをさらに備え、
上記クライアントからClientHelloを受信すると、上記記憶装置に上記外部サーバのセッション初期化処理で得られたデータが記憶されているか否かを確認し、前記データが記憶されていない場合には、上記外部サーバに対してセッション初期化処理を要求する情報（以下、初期化処理要求情報という。）を送信するように制御を行い、上記記憶装置に前記データが記憶されている場合には、上記外部サーバに対して初期化処理要求情報を送信しないように制御を行う第３制御部を上記サーバはさらに備えている
ことを特徴とする請求項１に記載のＳＳＬ／ＴＬＳ準拠システム。
【請求項４】
ＳＳＬ／ＴＬＳプロトコルに準拠して、サーバで少なくとも鍵取得処理、署名検証処理が行われ、サーバとクライアントの間で相互認証して暗号通信を行うＳＳＬ／ＴＬＳ準拠方法において、
上記サーバの第１制御部が、上記クライアントからClientKeyExchangeを受信した後、ClientKeyExchangeを上記サーバの記憶装置に記憶する制御を行う第１ステップと、
上記サーバの第１制御部が、上記クライアントからClientVerifyの受信を待って署名検証処理を実行するように制御する第２ステップと、
上記サーバの第１制御部が、署名検証に成功した場合に、上記記憶装置に記憶されたClientKeyExchangeを用いて鍵取得処理を実行するように制御する第３ステップを有する
ことを特徴とするＳＳＬ／ＴＬＳ準拠方法。
【請求項５】
上記サーバの第２制御部が、上記クライアントからClientHelloを受信すると、上記記憶装置に上記サーバのセッション初期化処理で得られたデータが記憶されているか否かを確認し、上記記憶装置に前記データが記憶されていない場合には、上記サーバのセッション初期化処理を行うように制御し、上記記憶装置に前記データが記憶されている場合には、上記サーバのセッション初期化処理を行わないように制御するセッション初期化制御ステップと、
上記サーバの第１制御部が、署名検証に成功すると、上記記憶装置に記憶されている前記データを消去する処理を行う第４ステップと
を有する
ことを特徴とする請求項４に記載のＳＳＬ／ＴＬＳ準拠方法。
【請求項６】
上記サーバの第３制御部が、上記クライアントからClientHelloを受信すると、上記記憶装置にセッション初期化処理を行う外部サーバのセッション初期化処理で得られたデータが記憶されているか否かを確認し、前記データが記憶されていない場合には、上記外部サーバに対してセッション初期化処理を要求する情報（以下、初期化処理要求情報という。）を送信するように制御を行い、上記記憶装置に前記データが記憶されている場合には、上記外部サーバに対して初期化処理要求情報を送信しないように制御を行うセッション初期化委託ステップと、
上記サーバの第１制御部が、署名検証に成功すると、上記記憶装置に記憶されている前記データを消去する処理を行う第４ステップと
を有する
ことを特徴とする請求項４に記載のＳＳＬ／ＴＬＳ準拠方法。
【請求項７】
ＳＳＬ／ＴＬＳプロトコルに準拠して、少なくとも鍵取得処理、署名検証処理が行われ、クライアントとの間で相互認証して暗号通信を行うＳＳＬ／ＴＬＳ準拠サーバにおいて、
上記サーバが、
上記クライアントからClientKeyExchangeを受信した後、ClientKeyExchangeを上記サーバの記憶装置に記憶する制御を行い、上記クライアントからClientVerifyの受信を待って署名検証処理を実行するように制御し、次いで、署名検証に成功した場合に、上記記憶装置に記憶されたClientKeyExchangeを用いて鍵取得処理を実行するように制御する第１制御部を備えている
ことを特徴とするＳＳＬ／ＴＬＳ準拠サーバ。
【請求項８】
上記クライアントからClientHelloを受信すると、上記記憶装置に上記セッション初期化処理で得られたデータが記憶されているか否かを確認し、上記記憶装置に上記セッション初期化処理で得られたデータが記憶されていない場合には、セッション初期化処理を行うように制御し、上記記憶装置に上記セッション初期化処理で得られたデータが記憶されている場合には、セッション初期化処理を行わないように制御する第２制御部をさらに備えている
ことを特徴とする請求項７に記載のＳＳＬ／ＴＬＳ準拠サーバ。
【請求項９】
上記クライアントからClientHelloを受信すると、上記記憶装置にセッション初期化処理を行う外部サーバのセッション初期化処理で得られたデータが記憶されているか否かを確認し、前記データが記憶されていない場合には、上記外部サーバに対してセッション初期化処理を要求する情報（以下、初期化処理要求情報という。）を送信するように制御を行い、上記記憶装置に前記データが記憶されている場合には、上記外部サーバに対して初期化処理要求情報を送信しないように制御を行う第３制御部をさらに備えている
ことを特徴とする請求項７に記載のＳＳＬ／ＴＬＳ準拠サーバ。
【請求項１０】
請求項７から請求項９のいずれかに記載されたＳＳＬ／ＴＬＳ準拠サーバとしてコンピュータを機能させるためのプログラム。
【請求項１１】
請求項１０に記載のプログラムを記録したコンピュータに読み取り可能な記録媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公開番号】特開２００９−２０６５６８（Ｐ２００９−２０６５６８Ａ）
【公開日】平成２１年９月１０日（２００９．９．１０）
【国際特許分類】
【出願番号】特願２００８−４４１２０（Ｐ２００８−４４１２０）
【出願日】平成２０年２月２６日（２００８．２．２６）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
【公開日】平成２１年９月１０日（２００９．９．１０）
【国際特許分類】
【出願日】平成２０年２月２６日（２００８．２．２６）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
[ Back to top ]