3 Minutes NetWorking Supplement
No.23

3Minutes NetWorking Supplement

補講第23回IPsec(3) SAパラメータとHMAC

■ リプレイアタック対策

おねーさん

おね〜さんと、

ほげたん

ほげたんのっ!!

おねーさん

3 Minutes Networking、

ほげたん

Supplement !!

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

セキュア化パラメータ

[FigureSP23-01:SAとセキュア化パラメータ]

おねーさん

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

ほげたん

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

おねーさん

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

  • Security Parameter Index(SPI)
  • シーケンス番号カウンタ、オーバフローフラグ
  • リプレイ防御ウィンドウ
  • ESP暗号化アルゴリズム・共通鍵・IV
  • AH/ESP認証アルゴリズム・鍵
  • SA有効期間
  • IPsecモード(トランスポート/トンネル)
  • ステートフルフラグメントチェックフラグ・バイパスDFビット・Path MTU
  • DSCP、バイパスDSCP
  • トンネルモード始点アドレス、終点アドレス
ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

[FigureSP23-02:リプレイ防御]

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

[FigureSP23-03:カウンタのオーバフロー]

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

戻るけど大丈夫。

[FigureSP23-04:SAの再構築によるリプレイ防御]

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

  • (シーケンス番号カウンタ)オーバフローフラグ
    • TRUE … カウンタがオーバフロー時に「SAを再構築する」
    • FALSE … カウンタがオーバフロー時には「カウンタをゼロにする」(リプレイ防御機能なし)
おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

[FigureSP23-05:シーケンス番号の改ざん]

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

■ IPsecフラグメント化

おねーさん

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

ほげたん

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

おねーさん

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

[FigureSP21-03:トランスポートモード]

おねーさん

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

[FigureSP21-04:トンネルモード]

ほげたん

確かに。もともとセキュア化する前の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にして送ることで調べるの。

[FigureSP23-06:MTU探索]

ほげたん

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

おねーさん

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

[FigureSP23-07:IPsecによるフラグメント化]

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

トランスポートモードの再フラグメント化

[FigureSP23-08:トランスポートモードの再フラグメント化]

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

トンネルモードなら?

おねーさん

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

トンネルモードの再フラグメント化

[FigureSP23-09:トンネルモードの再フラグメント化]

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

フラグメント化とセレクタ

[FigureSP23-10:フラグメント化とセレクタ]

ほげたん

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

おねーさん

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

  • ステートフルフラグメントチェックフラグ
    • TRUE … フラグメント化されているパケットはおなじSAを使用する
    • FALSE … フラグメント化されているパケットはそれぞれ別のSAを使用する
ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

  • バイパスDFビット
    • TRUE … 元のIPヘッダのDFビットの値をそのまま使用する
    • FALSE … 新たにDFビットを設定する。この場合、DFビットの値も設定する
  • DSCP
    • 新しいIPヘッダで使用するDSCP値を設定する
  • バイパスDSCP
    • TRUE … 元のIPヘッダDSCP値をそのまま使用する
    • FALSE … 新たにDSCP値を設定する。この場合、DSCP値も設定する
おねーさん

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

ほげたん

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

■ 認証アルゴリズム

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

[FigureSP17-01:改ざんの検出]

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

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

ほげたん

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

おねーさん

そう、MAC。MACはSSL/TLSでも使われたりしてる技術なんだけどね。IPsecで使用されるMACはHMAC-SHA-1-96AES-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でダイジェストを作るんだけど。その方法はこうね。

[FigureSP23-11:HMAC-SHA-1-96]

ほげたん

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

おねーさん

それはおね〜さんに言われてもなー。まぁ、暗号化よりハッシュの方が処理が軽いからこの方法が選ばれたんだけどね。ともかく、このダイジェスト、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モードを説明した図を見て?

[FigureSP15-04:ブロック暗号化のモード]

おねーさん

これの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分間ネットワーク、

ほげたん

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

64ビット
IPsecバージョン3から64ビット。バージョン1・2は32ビット。
メッセージ認証コード
[Message Authentication Code]
鍵付きメッセージ認証コード
[keyed-Hashing for Message Authentication Code]
ほげたんほげたんの今日のポイント
  • SAを使用する際に必要なパラメータをSA確立時に設定する。
  • IPsecにはリプレイアタック対策がとられている。
    • シーケンス番号・リプレイ防御ウィンドウでリプレイ対策する。
    • AHまたはオプション付きのESPでIKEによるSA構築でないとリプレイ対策はできない。
  • IPsecではフラグメント化を行う場合がある。
  • 改ざん防止のためメッセージ認証コードをデータに付加する。
    • アルゴリズムとしてHMAC-SHA-1-96かAES-XCBC-MAC-96を使う。
    • 使用するアルゴリズムと鍵をSA確立時に決定しておく。

3 Minutes NetWorking Supplement No.23

管理人:aji-ssz(at)selene.is.dream.jp