■ リプレイアタック対策

おね〜さんと、

ほげたんのっ!!

3 Minutes Networking、

Supplement !!

さって〜。前回はIPsecのセキュリティポリシーとSAについて話したわけだけど。結局、セキュリティポリシーとSAって何？

セキュリティポリシーは、インバウンド・アウトバウンドのパケットに対して、BYPASS・DISCARD・PROTECTのどの処理を行うか決定するもの、だよ。IPsecのセキュリティゲートウェイに届いたパケットはこのどれかの処理が行われるんだよ。

そうね、そのセキュリティポリシーの集合体をSPDと呼ぶんだったわよね。で、SAは？

セキュリティポリシーでPROTECTだった場合に、IPsecによるセキュア化が行われるわけだけど。IPsecで使われる仮想的な通信路がSAだったよね。セキュア化に使用するパラメータの合意だとかなんとか。

うん、そうそう。双方でセキュア化のパラメータが一致させることによって、仮想的な通信路ができる。これがSA、ね。

図のXとYはパラメータが一致するから、Yは送られたパケットのセキュア化を解除できるけど、XとZはパラメータが一致しないのでZは送られたパケットのセキュア化を解除できない。

だから、XとYは「セキュア化されたやりとり」ができる。つまり、XとYの間には「セキュア化された通信路」があると考えるんだよね、おね〜さん。

そゆこと。それが「SA」ね。IPsecでセキュア化された通信を行う場合、このSAをセキュリティゲートウェイ間で構築するってことね。んでね、このセキュア化に使うパラメータには次のようなものがあった、と。

うん、なんか一杯あるよね。何に使うのかわからないものもあるんだけど？

今回はこのSAパラメータについて説明していきましょう。まず、IPsecのリプレイアタック対策のためのパラメータから説明しましょう。「シーケンス番号カウンタ・オーバフローフラグ・リプレイ防御ウィンドウ」の3つね。

リプレイアタック対策？ そういえば、IPsecは「リプレイ対策」があるって話だったよね。

リプレイアタックについては、前Kerberosのところで話したっけ。簡単にいえば、セキュア化されているパケットをそのまま送ることで、セキュア化されたパケットの中身自体はわからなくてもよいって攻撃だったわね。

そうそう。結構嫌な攻撃だよね。

これをIPsecでも防ぐことができるの。えっと、まず最初に、送信されるIPsecのパケットにはシーケンス番号が振られる。これは最初のパケットを1として、それ以降1ずつ増えていくのね。

ふむふむ。パケットに番号をつける、と。それで？

後は単純、おなじシーケンス番号のパケットはリプレイアタックとみなして破棄する。

それはなんというか、ずいぶんとシンプルな対策だね。

そのために使用するのがシーケンス番号カウンタとリプレイ防御ウィンドウ。これを使って、シーケンス番号のチェックを行うわけね。

シーケンス番号カウンタ？ リプレイ防御ウィンドウ？ なにそれ？

ん〜、言葉で説明すると結構面倒くさいので、図でいきましょ。まぁ、TCPのスライディングウィンドウっぽいもの、かな？

ふむふむ。確かにスライディングウィンドウっぽいといえばっぽいかな？ つまり、届いたシーケンス番号を確認しておくのが「シーケンス番号カウンタ」と。

そうなるわね。これで届いたシーケンス番号のパケットが「未着パケット」か「既着パケット」か判別して、「既着パケット」ならリプレイアタックとみなして破棄する、と。

んで、リプレイ防御ウィンドウ？ これの意味がいまいちわからない。

任意の値で決定されたウィンドウで、受信を許可するシーケンス番号の範囲を決定するもの、ってことね。この範囲外で古いシーケンス番号のパケットは破棄しちゃうわけ。

んでもさ、図だと4番が未着でさ。先にそれ以降のパケットが届いちゃって、ウィンドウの範囲外に4番がなっちゃったから、4番を受信しても破棄しちゃってるよ？ これでいいの？

これは「遅く届きすぎたパケットはリプレイアタックとみなす」ってことね。通常ウィンドウは十分な大きさで設定されるから、あまりに遅く届いたパケットは「不自然」って扱いにしちゃって、いちいちチェックせず破棄しちゃうのよ。

まぁ、確かにあまりに遅く届いたら不自然かな。ちなみにウィンドウのサイズって普通どれぐらい？

RFCでは最低でも32、64が推奨。さて、このリプレイ防御機能だけどいくつか注意点があるの。まずリプレイ防御機能は受信側が使用の有無を決定するってことが1つ。

ふ〜ん。送信側はそれをどうやって知るの？

送信側はデフォルトで有効であると考えなきゃダメね。もし使用しないなら、IKEでSA確立時にそれを通知すること。

IKE。あれだよね、SAを構築する際に、事前にパラメータを交渉するプロトコルだったよね。

そう、それね。で、次がわりと大事なポイント、IKEを使わない手動パラメータ設定の場合リプレイ防御機能は使用できない。使えないことはないんだけど、基本的に使用しない。

え？ なんで？ それってセキュリティ的にまずくない？

それは、シーケンス番号の大きさが問題なの。シーケンス番号は今は64ビットなんだけど、前は32ビットだったのね。つまり2の32乗 - 1個のパケットを送っちゃうとオーバフローしてカウンタがゼロに戻るの。

ゼロに戻っちゃうと、困るの？

そりゃ困るでしょ。ゼロにもどっちゃって、次に1番が送られてきたとすると、この1番と、前の1番の区別はどうやってするのよ？ それに、リプレイ防御ウィンドウから見れば古いシーケンス番号になっちゃうのよ？ そしたら破棄しちゃうでしょ。

確かにこれは困るね。じゃあ、もしシーケンス番号カウンタより大きい数の個数のパケットを送りたかったらどうするの？

リプレイ防御機能を使用する場合、シーケンス番号カウンタがゼロに戻ることは許されない。よって、ゼロに戻る場合、今のSAを破棄して新しいSAを構築するの。

新しいSAを構築？ それで防げるの？ だってさ、SAが確立されるとシーケンス番号は初期化されてゼロにどっちにしろ戻らない？

戻るけど大丈夫。

なるほど。SAが変わったせいでパラメータが変更されるから、以前に盗聴したパケットはダメになっちゃうんだ。

そういうこと。IKEを使わない静的なパラメータ設定で構築されるSAでは、パラメータは手動で決まった値でしょ？ 新たにSAを構築しなおしたとしてもおなじパラメータを使ってSAを確立しちゃうからダメなのよ。

ははぁ、IKEを使えばパラメータは動的に変更するから大丈夫ってことなんだ。だから「IKEを使わない手動パラメータ設定の場合リプレイ防御機能は使用できない」ってことなんだね。

そういうこと。でね、パラメータに「オーバフローフラグ」ってあったでしょ。これは次のような意味ね。

FALSEの場合、シーケンス番号をパケットにつけて送るけど、チェックまではしない。単に番号をつけるだけ、ね。

だったらシーケンス番号なしにすればいいのに。

そんなことおね〜さんに言われてもな。さて、最後のポイント。ESP使用時にはオプションのメッセージ認証を使用しなければリプレイ防御機能は使用できない。メッセージ認証を使用しないと、リプレイ防御できないってことね。

なんで？ AHはいいの？ ESPだけ？

AHはいいの。ESPのメッセージ認証オプションなしの場合だけ。何故かって言うと、シーケンス番号の改ざん防止ができないから。

と、このように正規のパケットが破棄されてしまうという攻撃をしかけることができちゃうわけね。

ESPでメッセージ認証オプションなしだと、「シーケンス番号の改ざん」の防止ができないから、リプレイ防御ウィンドウが動いちゃうんだね。なんていうかリプレイ防止機能を逆手に取った見事な攻撃って感じだね。

そういうこと。メッセージ認証の範囲についてはAHやESPの説明のところで話すわね。とりあえず、オプションなしのESPではリプレイ防御機能は使えない、ってことね。

まとめると、「AHまたはオプション付きのESP」で「IKEによるSA構築」じゃないとリプレイ防御機能は使えない、ってことだね。

■ IPsecフラグメント化

さてさて、次のパラメータの説明をいきましょう。「ステートフルフラグメントチェックフラグ・バイパスDFビット・Path MTU」の3つ、つまりIPsecでのフラグメント化についてのパラメータね。

フラグメント化？ えっと、MTUに収まるようにIPパケットを分割するんだったよね。それをIPsecで行う？

そう、それね。何故かっていうと、IPsecでは新たにヘッダを追加するのでMTUを超えてしまうことが多いの。えっと、前説明したトランスポートモードの図でもわかるでしょ？

トンネルモードだと、さらにIPヘッダも追加されるから、MTUを超えることが多いのね。

確かに。もともとセキュア化する前のIPパケットがMTUサイズぎりぎりだったら、トランスポートモードでもトンネルモードでもヘッダが追加されるから確実にフラグメント化が必要だよね。

そういうことね。まず、セキュリティゲートウェイはSAで使われる経路のMTUサイズを記憶するってことが最初のポイント。これがSAパラメータのPath MTUね。

へぇ、どうやって？

ん〜、これはセキュリティゲートウェイや、IPsecソフトによって違うんだけど。ICMPを使ってMTU探索をする場合もあるし、実際に送信して確かめる場合もあるし。

MTU探索？ なにそれ？

IPヘッダにはDFビットってのがあるの。これはフラグメント化を許可する/しないビットね。これが「TRUE」のパケットは「フラグメント化してはいけない」。もしフラグメント化が必要な場合、ICMPでエラーを返す。

へぇ…、これかな？ ICMPエラー、タイプ3（Destination Unreacheable）のコード4（Fragmentation Needed and DF was Set）？

うん、それ。それでMTU探索は一般的には、Ping、つまりICMPエコーをDFビットをTRUEにして送ることで調べるの。

ふむふむ。ちょいとめんどっちいね。

これを使ってセキュリティゲートウェイ間の最少MTUを調べるわけね。さて、セキュリティゲートウェイでフラグメント化が必要になった場合だけど、どのタイミングでフラグメント化するかというと…、前回のSPDの説明で使った図を改良するわね。

送信側はIPsec処理後にフラグメント化、受信側は受け取ってIPsec処理前にデフラグメント化、だね。

そういうことね。あと、このIPsecによるフラグメント化の注意点。まずすでにフラグメント化されているパケットはトランスポートモードではさらにフラグメント化できない。

え？ なんで？ トンネルモードはいいの？

トンネルモードなら大丈夫。トランスポートモードだけ。これはトランスポートモードのIPヘッダが元のIPヘッダを使用しているから起きる問題なの。MTUは1020、AH/ESPヘッダは100として考えてみるとこうなるの。

単純にデフラグメント化を行うとこうなっちゃう。おかしいわよね、AH/ESPヘッダが2つ、しかもデータの間に挟まっちゃうんだから。こうならないためにはどうするの？

う〜んと、デフラグメント化する際に、パケットC・DでパケットAにデフラグメント化、パケットE・FでパケットBにデフラグメント化。そして、パケットXにデフラグメント化、かな？

それはIPのデフラグメント化処理では無理ね。パケットC〜Fは元パケットXのIPヘッダをそのまま使っているから、まぁ一部は書き換えているけど、あくまでもC〜FはXのフラグメント化なの。よって、いきなり4つをまとめてデフラグメント化しちゃう。

トンネルモードなら？

トンネルモードなら新しいIPヘッダがついた「別のIPパケット」の扱いになるから、大丈夫よ。

新しいIPヘッダでフラグメント化するから、パケットC・DはパケットAのフラグメント化、パケットE・FはパケットBのフラグメント化。よってパケットG、パケットHにデフラグメント化される。

なるほど。トランスポートモードの場合は再フラグメント化できない、と。しなきゃいけない場合はどうなるの？

エラーね。ICMPタイプ3コード4を返すことになるわ。さて、IPsecフラグメント化の注意その2。これもすでにフラグメント化されている場合の話だけど、フラグメント化されるとTCP/UDPヘッダがあるIPパケットとないIPパケットにわかれちゃうわよね。

そうだね。先頭のフラグメント化パケットにはTCPヘッダがあるけど、それ以降にはないことになるよね。

そうすると、セレクタでポート番号やプロトコルを指定しているセキュリティポリシーで困っちゃう。

あぁ、そうか。セレクタにプロトコルがあった場合、先頭IPパケットはTCPヘッダがあるからいいけど、2つ目はないから別のセキュリティポリシーが選ばれちゃう可能性があるんだ。

そういうこと。こうなると違うSAで運ばれちゃうことがあるわけね。これでもいいんだけど、ここで使うのが「ステートフルフラグメントチェックフラグ」。

なるほど。元パケットがおなじなら、おなじSAで運ぼうって設定するのがステートフルフラグメントチェックフラグなんだ。

うん。いろいろ考えているわよね。え〜っと、あと何だっけ？ 「バイパスDFビット」か。これと「DSCP」「バイパスDSCP」はまとめて説明しましょ。これはトンネルモードの時の新IPヘッダの値をどうするか、というパラメータね。

DFビットはさっきのフラグメント化の禁止、DSCPはQoSで使う値だっけ。

そうそう、それね。で、トンネルモードで新しくつけるIPヘッダの値を次のように設定するの。

まぁ、要はトンネルモードで新しいIPヘッダをつける際に、元のIPヘッダの値を使うか使わないか、ってことね。

なるほど。「バイパス」がTRUEなら元のIPヘッダの値を使うよってことだね。

■ 認証アルゴリズム

SAのパラメータ、あと何があったっけ？ SPIは前回説明したSADを検索する際に使う値でしょ？ 暗号化はESPの時また説明するとして、次はメッセージ認証か。

メッセージ認証。データの改ざん防止だっけ。

そう、それね。え〜っと、PKIの改ざん防止、メッセージ認証はどんなんだっけ？

「ディジタル署名」だよ。データのハッシュ値に送信元の秘密鍵で暗号化する。

そうだったわね。さて、メッセージ認証の考え方はPKIでもでてきたコレね。

改ざん防止、というか改ざんの検出のためにおなじデータを送信する、だね。

ただし、改ざん検出用のデータ自体を改ざんされないようにする、改ざん検出用のデータのサイズを小さくすることが必要よね。

うん。だからPKIでは「データのハッシュ値」を「送信元の秘密鍵で暗号化」したよね。

そうね。メッセージ認証で使用するにはディジタル署名は優れた方式だけど、PKIというインフラが存在しないと証明書の信頼性を確保できないからダメなのよね。それに、証明書って結構面倒だし。

面倒って、まぁ、確かにそうかもね。インフラが必要だしね。

でしょ。なので、IPsecでは別の手法を使います。メッセージ認証のアルゴリズムとしてメッセージ認証コード（MAC）と呼ばれるものを使うの。

メッセージオーセンティケーションコード。まっく？

そう、MAC。MACはSSL/TLSでも使われたりしてる技術なんだけどね。IPsecで使用されるMACはHMAC-SHA-1-96とAES-XCBC-MAC-96。HMAC-MD5-96もあるけど、MD5は強度が弱いからちょっとね。一般にはHMAC-SHA-1-96を使うわね。

HMAC-SHA-1、ってことはハッシュ関数のSHA-1と関係があるってことだよね。

もちろん。ディジタル署名とおなじように改ざん検出コードの作成にハッシュ関数を使ったダイジェストを付与するの。このダイジェストのことをMACって呼ぶのね。ただし、単純にダイジェストをつけただけじゃダメよね？

うん。ダイジェスト自体を改ざんしちゃえばいいだけの話だからね。ディジタル署名ではダイジェストを改ざんされないように鍵で暗号化してたよね。

そうよね。なので、このMACも改ざんできない鍵付きメッセージ認証コード（HMAC）を使うの。RFCだとRFC2104ね。▼ link

鍵付き？ なんの鍵？

HMAC用の共通鍵。HMAC用に送受側で同一の鍵を保持しておくのよ。SAパラメータにもあるでしょ、「AH/ESP認証アルゴリズム・鍵」って。どの認証アルゴリズムを使って、それに使用する鍵をSAで決定しておくわけね。

共通鍵。ってことは他の人には内緒なんだね。

そりゃそうよね。さて、この秘密の共通鍵を使ってSHA-1でダイジェストを作るんだけど。その方法はこうね。

面倒くさっ!! 共通鍵があるならさ、素直に暗号化しちゃってディジタル署名にしちゃえばいいのに。

それはおね〜さんに言われてもなー。まぁ、暗号化よりハッシュの方が処理が軽いからこの方法が選ばれたんだけどね。ともかく、このダイジェスト、MACは鍵がないと作れないのはわかる？

うん。鍵と定数から生成されるK1、K2を含めてハッシュしてるから。K1とK2がないとこのH2は求まらないよね。

でしょ。よって、このMACは改ざんされないわけね。

ん〜、おね〜さん? なんで先頭の96ビットしか使わないの？

もともとはIPsecのバージョン1とMD5が原因なんだけどね。バージョンがあがって、SHA-1になっても96ビットにしようって話なのよ。160ビット全体を送るより96ビットの方が攻撃者に与える情報量が少ないからいいんじゃね？ って話らしいわよ。

ふ〜ん。じゃあAES-XCBC-MAC-96は？

AES-XCBC-MAC-96は、RFC3566で定義された方式ね。AESのCBCモード、ブロック長128ビットと同じ方法を使ってMACを作り出すの。▼ link

AESのCBCモード？ ということは暗号化を使うの？

そうよ。かなりややっこしい方式だから、簡単に説明するわね。以前CBCモードを説明した図を見て？

これの6番からの方式がCBCモードよね。1つ前に暗号化したものとXORして暗号化するっていう方式。で、これの一番最後に暗号化されたブロックのうち先頭96ビットをMACとして使うの。

一番最後に暗号化されたブロック…、図でいうと一番右のブロックだね？

そうね。ブロック長は128ビットだから、この128ビットのうち先頭96ビットをMACとして使うってことね。

へぇ。IVとかはどうするの？

IVは固定値を使う。他にも用意した共通鍵ではなく、固定値を共通鍵で暗号化した値を暗号化する鍵にしたりしてるんだけど。まぁ、基本的にAES-CBC-128の最後のブロックの96ビット、と覚えておけばいいわ。

ん〜、でもさおね〜さん。HMAC-SHA-1のややっこしい方式を使うのはハッシュが暗号化より早いからだよね？ AESだと遅くならない？

あ〜…、実はね、ほげたん。AESってかなり高速なアルゴリズムでね。SHA-1よりも速かったりする場合があるのよ。だからAES-XCBC-MACでも問題なかったり〜。

さっきと言ってることが違うよ、もう。

んにゃんにゃ。それでもSHA-1は3DESよりは早いのよ、やっぱり。AESの登場で変わってきたってことかな。実際、RFCでもHAMC-SHA-1は必須（MUST）、AES-XCBC-MACは実装すべき（SHOULD+）だったり。さすがAdvanced、すごいわよねAES。

それは確かに。高速で強固な暗号化アルゴリズムだかね、AESは。

さてさて、このHAMC-SHA-1-96かAES-XCBC-MAC-96のどちらかを使ったMACをつけて、改ざんの検出を行うわけね。なので、SA確立時に使用するアルゴリズムと鍵を決めておくってことね。

うん、了解。

あとのパラメータ、「SAの有効期限」はIKEの時に、「IPsecモード」と「トンネルモード始点アドレス、終点アドレス」はモードの時に説明するから。これでSAのパラメータは説明し終わったってところかな。SAのパラメータの意味わかった、ほげたん？

SAを使用する際に必要なパラメータってことだね。

まぁ、要約しちゃうとそうなるわね。IPsecでの機能や動作を決定するパラメータってことね。

だよね。

じゃあ今回はこれぐらいにして、と。まった次回。
おね〜さんと、

ほげたんのっ!!

3分間ネットワーク、

サプリメントでした〜〜〜っ!!