## page was copied from DnsTemplate ##master-page:HelpTemplate <> <> {{{ D. J. Bernstein [Translated into Japanese by MAENO Toshinori] Internet publication djbdns }}} = DNS 偽造(forgery) = あなたのネットワークにアクセスできる攻撃者なら 簡単にあなたのDNS問合せに対して返答を偽造できる。 例えば、彼はあなたの送るメイルを盗み見たり、 ``secure'' web トランズアクションを傍受したりできる。 DNS サーバを動かしているなら、 あなたのネットワークにアクセスできる攻撃者は 他の人に対してのDNSサーバの返事を簡単に偽造できる。 例えば、彼はあなた宛のメイルを横取りしたり、 webページを置き換えたりできる。 クライアントのネットワークや サーバのネットワークにアクセスできなくても インターネットのどこからでも攻撃者は返答を偽造できる。 ただし、たやすくはないが。 特に、彼は問合せ時間、DNS ID (16 bits), DNS 問合せポート(15-16 bits) を当てなければならない。 dnscache プログラムは ID と問合せポートについて、 予測が極めて困難になるように暗号生成器を使っている。 しかしながら、 * ランダムに20億から30億回試みる攻撃者なら、 少くとも一度は成功しそうである。 * 数千万回のゲスで colliding attack には十分だろう; * BIND に対してなら、10 万ゲスが適当なところだ。 BIND は問合せに同じポートを使い続けるから。 * 古い BINDに対してなら、colliding attack は1000回のゲスで十分だ。 2002 年 11 月 現在、CERT はパニック状態だ。 彼等はいかにこれが自明か分っていなかった。 私が 2001 年 7 月の posting で 解説したというのに。 DNS プロトコルでもっと大きなクッキーを使っていたなら、 blind attacks を事実上不可能にできたろうに。 (Caches could achieve a similar effect without protocol changes by repeating queries a bunch of times with different ports and IDs, at the expense of speed and reliability.) しかしながら、それでもネットワークに(物理的に)アクセスできる攻撃者なら、 DNS 返答を騙ることができる。 == 公開鍵署名(Public-key signature)システム == 現代暗号にはなりすましを防ぐツールがある： 公開鍵署名(Public-key signature)システムだ。 簡単に言うと: * 鍵を生成して公開する。 * あなたは、そしてシステムが安全なら、あなただけが、 その鍵を使って文書に署名できる。 * 誰でもその文書があなたの鍵を使って署名したものだと確認できる。 署名は文書とキーの複雑な数学関数である。 == DNSSEC: 理論と実践 == DNSSEC とはひとつの中央組織(Network Solutions)で すべての .com DNS レコードに署名するという プロジェクトである。 以下は1993年に提案された案である。: Network Solutions はキーを生成し公開する。 各 *.comはキーを生成し、自身の DNS レコードに署名する。 例えば、Yahoo はキーを生成して、それを使って、 yahoo.com DNS レコードに署名する。 Network Solutions は 各 *.com キーに署名する。 例えば、Yahoo はなんらかの安全な経路を使って Network Solutions に自分のキーを渡し、 Network Solutions はそのキーがyahoo.com のキーであることを証明する文書に署名する。 インタネット上のコンピュータはNetwork Solutions キーを使うことにより、 相応しい署名がされていないDNS レコードは受け取らないようにする。 しかしながら、2002年 11月現在、 Network Solutions はこれをまったく行っていない。 Network Solutions キーは存在しない。 Network Solutions の署名も存在しない。 Network Solutions が *.com キーを最初に収集するための 安全なチャネルが存在しない。 -- 事実上、仕掛けそのものも存在しない --。 もっと悪いことに、DNSSEC プロトコルは現在も大きく変更されている。 Paul Vixie は 2002.11.21 に以下のように書いた: We are still doing basic research on what kind of data model will work for dns security. After three or four times of saying "NOW we've got it, THIS TIME for sure" there's finally some humility in the picture... "wonder if THIS'll work?" ... It's impossible to know how many more flag days we'll have before it's safe to burn ROMs that marshall and unmarshall the DNSSEC related RR's, or follow chains trying to validate signatures. It sure isn't plain old SIG+KEY, and it sure isn't DS as currently specified. When will it be? We don't know. What has to happen before we will know? We don't know that either. ... 2535 is already dead and buried. There is no installed base. We're starting from scratch. DNSSEC ---for example, BIND 9's RFC 2535 implementation-- はあなたのコンピュータを DNS の偽造から守るために インストールできるソフトウェア機能だとして 何年も偽りの宣伝がなされてきた。 事実は DNSSEC をインストールしても「なにも」守ってくれるものではなく、 今見えるかぎりの将来もなにもしないままであり続けるだろう。 私には DNSSEC を実装する手間をかける予定はない。 (1) a stable, sensible DNSSEC protocol (2) DNSSEC を展開するための詳細で堅固で信用できる計画 を見るまでは。 == Nym-based security == DNSSEC がいつの日か put into place になったとしても、 Network Solutions 自身を通しての攻撃は避けられない。 Network Solutions の社員が買収されたらどうなる。 Network Solutions のすべてのコンピュータは安全だろうか。 Network Solutions の重要なコンピュータのたった一台に侵入できれば、 攻撃者はインタネット全体をコントロールできることになる。 2001年 1月のこと、ある攻撃者は Network Solutionsの親会社であるVeriSignを騙して 偽の `Microsoft Corporation'' ActiveX キーに認証させた。 こういう人々を信用せよというのだろうか。 公開鍵署名を使って偽造をふせぐ別の方法もある。 それは DNSSEC より高速で簡単であり、 そして、中央の権威に依存しない。 欠点は憶えるには長すぎるドメイン名を使うことである。 一方では、ユーザは長いwebアドレスを憶えるという問題に対して 満足できる解決としてコンピュータブックマークを使うようだ。 ビジネスがもっと電子的に遂行されるようになっていけば、 長いドメイン名は問題ではなくなるだろう。 簡単なアイデアである。 それぞれのコンピュータには コンピュータのnym、つまり コンピュータの公開鍵のフィンガープリントを含めた名前をつける。 他のコンピュータは この名前についての対応する公開鍵のもとでの署名がない DNSレコードは破棄する。 djbdns における最優先事項は nym-based セキュリティのサポートである。 2002-11-28 訳：前野年紀 == whois == {{{ }}} == history == {{{ }}} ---- CategoryDns CategoryWatch CategoryTemplate