AE<- 目次 ->AG


F. セキュリティ解析 English

(準備中)

TLS プロトコルは、安全ではないチャネル上で通信するクライアントとサーバーとの間で、安全なコネクションを確立するように設計されている。このドキュメントでは、さまざまな伝統的仮定を行っている。これらの仮定には、攻撃者がかなりのコンピュータリソースを持っており、プロトコルの外からはシークレット情報を得ることができないという仮定が含まれている。攻撃者は、通信チャネル上を送信されるメッセージを捕獲し、変更し、削除し、再送し、その他みだりにいじりまわす能力を持っていると仮定している。この付録では、TLS がさまざまな攻撃に耐えるためにどのように設計されているのかを概説する。

F.1. ハンドシェイクプロトコル English

ハンドシェイクプロトコルは、CipherSpec を選択し、マスターシークレットを生成する。そしてこれらにより、安全なセッションに関する主要な暗号パラメータが生成される。ハンドシェイクプロトコルはまた、信用のおける認証局によって署名された証明書を持つ 主体間における認証を、任意に行うことができる。

F.1.1. 認証と鍵交換 English

TLS は 3つの認証モードをサポートしている。: 双方の認証、サーバー認証と認証されないクライアントおよび完全な匿名である。サーバーが認証されるときは、そのチャネルはなりすまし攻撃に対しては安全であるが、完全な匿名セッションでは性質上そのような攻撃にさらされやすい。匿名サーバーはクライアントを認証することはできない。もしサーバーが認証されるときは、その証明書メッセージは、信用のおける認証局へ通じる、有効な認証局チェーンを提供していなければならない。同様に、認証されるクライアントは、サーバーで受理することのできる証明書を提示しなければならない。それぞれのパーティーでは、相手の証明書が有効であり、期間が切れていないか、または取り消されていないか、ということを確認する責任がある。

鍵交換プロセスの一般的な目的は、攻撃者との間ではなく、通信を行っているパーティーとの間でのみ、pre_master_secret を生成することである。 pre_master_secret は、master_secret を生成するのに使用される(第8.1章を参照)。 master_secretは、CertificateVerifyとFinishedメッセージ、暗号化鍵、MAC シークレットを生成するために必要である(7.4.8 節7.4.9 節、6.3 節を参照)。正しい Finished メッセージを送信することにより、2つのパーティーは、正確な pre_master_secret を知っていることを確認する。

F.1.1.1. 匿名鍵交換 English

鍵交換において RSA または Diffie-Hellman を使用することで、完全に匿名なセッションを確立することができる。匿名 RSA では、クライアントは ServerKeyExchange メッセージから抽出された、認証のされていないサーバーの公開鍵を使用して pre_master_secret を暗号化する。処理結果は、ClientKeyExchange メッセージで送信される。盗聴者はサーバーの秘密鍵を知らないため、盗聴者がpre_master_secret を復号することは不可能である。(ただし、本 書においては、匿名 RSA 暗号スイートは定義されていない。)

Diffie-Hellman では、サーバーの公開パラメータは ServerKeyExchange メッセージに含まれ、クライアントのパラメータは ClientKeyExchange メッセージで送信される。私有値を知らない盗聴者は、Diffie-Hellman 結果(すなわち pre_master_secret)を知ることは出来ない。

警告: 完全に匿名なコネクションでは、受動的な盗聴者に対する保護しか提供されない。改竄の行われない独立したチャネルを使用して Finished メッセージが攻撃者により置きかえられてはいないことを確認しない限り、能動的ななりすまし攻撃の懸念がある環境では、サーバー認証が必要となる。

F.1.1.2. RSA 鍵交換と認証 English

RSA では、鍵交換とサーバー認証には関連がある。公開鍵はサーバー証明書に含まれているものか、または ServerKeyExchange メッセージで送信される一時的 RSA 鍵である。一時的 RSA 鍵を使用した場合には、それらはサーバーの RSA または DSS 証明書により署名される。署名には、カレントのClientHello.random が含まれる。そのため、古い署名や古い一時的鍵は再利用できない。サーバーは 1つの一時的 RSA 鍵を、複数の共有セッションに使用することが出来る。

注: 一時的 RSA 鍵オプションは、サーバーでは長いビット長をもつ証明書が必要であるが、鍵交換処理においては政府により規制された鍵長制限に従わなければならない場合に有効である。

サーバー証明書の検証後、クライアントは pre_master_secret をサーバーの公開鍵で暗号化する。pre_master_secret を復号し、それにより正しい Finished メッセージを生成することにより、サーバーはサーバー証明書に対応する秘密鍵を知っていることを実証する。

鍵交換方式として RSA を使用した際には、クライアントは CertificateVerify メッセージ(7.4.8 節参照)により認証される。クライアントは、master_secret とこれまでのすべてのハンドシェイクメッセージから得られた値に対して署名を行う。これらのハンドシェイクメッセージには、ServerCertificate と ServerHello.random が含まれる。ServerCertificate は、署名とサーバーを関連付けるものである。ServerHello.random は、署名とカレントのハンドシェイクプロセスを関連付けるものである。

F.1.1.3. 認証を伴う Diffie-Hellman 鍵交換 English

Diffie-Hellman 鍵交換を使用する場合、サーバーは、固定 Diffie-Hellman パラメータを含む証明書を提供するか、または ServerKeyExchange メッセージにより、DSS または RSA 証明書により署名された一時的 Diffie-Hellman パラメータを送信する。一時的パラメータは、署名される前に hello.random 値によりハッシュされる。これは攻撃者が古いパラメータを再利用しないようにするためである。どちらの場合でも、クライアントは証明書または署名を確認し、パラメータがサーバーのものであることを検証することができる。

もしクライアントが固定 Diffie-Hellman パラメータを含む証明書を所有しているならば、その証明書には鍵交換に必要な情報がすべて含まれている。この場合クライアントとサーバーは、同じ Diffie-Hellman 値(すなわちpre_master_secret)を、通信するごとに生成することになる。pre_master_secret が必要以上にメモリ上に残ることを防ぐために、出来るだけ早く master_secret へ変換する必要がある。クライアントの Diffie-Hellman パラメータは、鍵交換を行うために、サーバーにより提供されるパラメータとの互換性が必要である。

もしクライアントが標準 DSS または RSA 証明書を所有している、もしくはクライアントが認証されないならば、クライアントは ClientKeyExchange メッセージにおいて、サーバーに対し一時的パラメータを送信する。そしてオプショナルで、自身を認証するために、CertificateVerify メッセージを使用する。

F.1.2. バージョンロールバック攻撃 English

TLS では、SSL バージョン 2.0 からのかなりの改良を含んでいるため、攻撃者は、 TLS の実行可能なクライアントとサーバーを、バージョン2.0 に戻すようにさせるかもしれない。この攻撃は、2つの TLS 実行可能なパーティーが SSL2.0 ハンドシェイクを使用している場合のみに起こりうる。

ランダムではない、PKCS #1 のブロック型 2 メッセージパディングを使用した解決方法は、洗練されていないが、これはバージョン 3.0 をサポートしているサーバーが攻撃を検出することの出来る、適度に安全な方法を提供する。この解決方法は、アプリケーションが指定した待ち時間を過ぎるまでに、鍵に対してブルートフォース攻撃を行い、(通常のパディングを行った)同じ鍵を含む新しい ENCRYPTED-KEY-DATA メッセージに交換する攻撃者に対しては安全ではない。この種の攻撃を懸念するパーティーでは、とにかく 40ビットの暗号鍵を使用すべきではない。PKCS パディングにおいての最後の 8バイトのパディングを変更しても、プロトコルで使用している、署名されたハッシュサイズや、RSA 鍵長に関するセキュリティには影響しない。なぜならば、入力ブロックサイズが 8 バイト増加した、ということと本質的に同等であるからである。

F.1.3. ハンドシェイクプロトコルに対する攻撃の検出 English

攻撃者は、通常パーティーが選択する暗号アルゴリズムとは異なった暗号を選択するように、ハンドシェイク処理に対して影響を及ぼそうとするかもしれない。多くの実装では、40ビットの輸出可能な暗号をサポートしており、またいくつかの実装では NULL 暗号と MAC アルゴリズムのサポートさえ行うかもしれないため、この攻撃には特別の関心を払う必要がある。

この攻撃を行うためには、攻撃者は積極的に 1つ以上のハンドシェイクメッセージを変更しなければならない。これが起きた場合、クライアントとサーバーはハンドシェイクメッセージのハッシュ値として異なった値を求めることになる。その結果、パーティーはお互いの Finished メ ッセージを受理することはない。 master_secret がなければ、攻撃者は Fishied メッセージを修正することができないので、その攻撃は発見されるであろう。

F.1.4. セッションの再利用 English

セッションを再利用することによってコネクションが確立されるとき、新しい ClientHello.random とServerHello.random 値は、セッションの master_secret と共にハッシュされる。もし master_secret が危険にさらされてなく、また暗号化鍵と MAC シークレットを生成するために使用されるハッシュ処理が安全であれば、コネクションは安全で、以前のコネクションから独立している。攻撃者は、安全なハッシュ処理 (SHA と MD5 の両方を使用する)を破ることなしに、既知の暗号化鍵または MAC シークレットを使用して、master_secret を危険にさらすことはできない。

クライアントとサーバーの両方が合意しない場合、セッションを再利用することはできない。どちらかのパーティーが、セッションが危険にさらされている、もしくは証明書の有効期間が切れた、または取り消されたと考えたときには、完全なハンドシェイクを強行するべきである。セッション ID の生存時間は、最大でも 24時間であることを提案する。なぜならば、master_secret を入手した攻撃者は対応するセッション ID の有効期限が切れるまで、危険にさらされているパーティーを装うことができるからである。比較的安全でない環境で実行されるアプリケーションでは、セッション ID を静的な記憶装置に書き込むべきではない。

F.1.5. MD5 と SHA English

TLS では、ハッシュ関数を非常に保守的に使用する。可能なところでは、ある 1つのアルゴリズムに非壊滅的な欠点があっても、プロトコル全体を壊さないことを確実にするために、MD5 と SHA の両方をタンデムに使用する。

F.2. アプリケーションデータの保護 English

master_secret は、ClientHello.random と ServerHello.random と共にハッシュされ、それぞれのコネクションにおいて使用される唯一のデータ暗号化鍵とMAC シークレットが作成される。

送信データは、送信される前に MAC により保護される。メッセージ再送またはメッセージ修正攻撃を防ぐために、MAC は MAC シークレット、シーケンス番号、メッセージ長、メッセージコンテンツ および 2つの固定文字列から計算される。メッセージタイプフィールドは、ある TLS レコード層クライアントへのメッセージが、他へリダイレクトされないことを確実にするのに必要である。シーケンス番号を使用することにより、メッセージの削除または再要求を行おうとする試みは確実に検出できる。シーケンス番号は 64ビットであるので、オーバーフローすることはほとんどない。ある 1つのパーティーからのメッセージを、他方のパーティーの出力メッセージの中に挿入することはできない。なぜならば、パーティーは独立した MAC シークレットを使用しているからである。同様に、サーバー書き出し鍵とクライアント書き出し鍵は独立しているため、ストリーム暗号鍵は一度だけしか使用されない。

攻撃者が暗号化鍵を解読したならば、その鍵で暗号化されるすべてのメッセージは解読される。同様に、MAC鍵が危険にさらされた場合には、メッセージ変更攻撃が可能となる。MAC は 、暗号化されるため、メッセージ変更攻撃は一般に、MAC を破ることと同時に、暗号化アルゴリズムを解読することが必要となる。

注: MAC シークレットは暗号化鍵よりも大きくしてもよいので、暗号化鍵が解読されたとしても、メッセージは改竄に対する耐性を持っている。

F.3. 最終注記 English

TLS が安全なコネクションを提供できるようにするためには、クライアントとサーバーの両方のシステム、鍵、およびアプリケーションは安全でなければならない。さらに、実装においてセキュリティエラーがあってはならない。

システムは、サポートしている最も弱い鍵交換アルゴリズム、最も弱い認証アルゴリズムと同じ程度の強度しか持っていない。そして信頼できる暗号関数だけが使用されるべきである。短い公開鍵、40 ビットの通信内容を暗号化する共通鍵暗号化鍵、および匿名サーバーを使用するときには、十分に注意すべきである。実装者とユーザは、どの証明書とどの認証局を受け入れるのかを決めるときには、十分に注意しなければならない。不遜な認証局により、大変な損害を受けることがある。


AE<- 目次 ->AG