 |
 |
記事検索 |
バックナンバー |
 |
||
|
||
【 2008/10/08 】 |
||
|
||
|
||
| ||
|
||
|
||
【 2008/09/24 】 |
||
|
||
|
||
| ||
|
||
|
||
【 2008/09/17 】 |
||
|
||
|
||
| ||
|
||
|
||
【 2008/09/03 】 |
||
|
||
|
||
| ||
|
||
|
||
【 2008/08/27 】 |
||
|
||
|
||
| ||
|
||
|
||
【 2008/07/30 】 |
||
|
||
|
||
| ||
|
||
|
||
【 2008/07/23 】 |
||
|
||
|
||
| ||
|
||
|
||
【 2008/07/16 】 |
||
|
||
|
||
| ||
|
||
|
||
【 2008/07/09 】 |
||
|
||
|
||
| ||
|
||
|
||
【 2008/07/02 】 |
||
|
||
|
||
| ||
|
||
|
||
【 2008/06/25 】 |
||
|
||
|
||
| ||
|
||
|
||
【 2008/06/18 】 |
||
|
||
|
||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
||||||||||||||||||||
|
||||||||||||||||||||
|
||||||||||||||||||||
| あなたの身近なセキュリティ | ||||||||||||||||||||
|
第8回：WWW編（6）暗号化の仕組み |
||||||||||||||||||||
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
||||||||||||||||||||
|
||||||||||||||||||||
|
||||||||||||||||||||
|
||||||||||||||||||||
|
||||||||||||||||||||
|
● 「この通信は暗号化されているので安全です」ってなに？ 「この通信は暗号化されているので安全です」。これは、ショッピングサイトなどでよく出てくる表記だ。この意味をあなたはどれだけ理解しているだろうか？ というのが今回のテーマである。よくインターネットの接続状況を模式的に表わす場合、ユーザー側とサーバー側の間にモヤモヤとした雲マークを書いて、中央に「インターネット」と書くことがある。ユーザーからすれば、どうやって接続しているかはあまり気にすることはないだろう。しかし、重要なデータをやり取りする場合には、雲マーク内での出来事を知っておいた方がよいかもしれない。 雲マークがモヤモヤしているのには意味がある。よく言われていることだが、「インターネット全体を統括管理している人はいない」ためだ。このため、もしかすると、ユーザーとサーバーの間に悪い人がいて、通信を傍受しているかもしれないし、傍受どころか中身を替えてサーバーに送っているかもしれない。はたまた、相手がサーバーと偽った悪人かもしれない。つまり、安全の保証がないのだ。 ● インターネットの「雲の中」を安全に通信できるようにするのが暗号化 インターネットで安全を語るためには、クライアントマシンが安全でもサーバーマシンが安全でも不十分だ。インターネットの「雲の中」にある経路をいかに安全にするかというのが重要になる。インターネットの「雲の中」がどうなっていても、通信を安全にするのが暗号化だ。データを暗号化することで、送受信するデータがインターネットの途中で傍受されたり、リアルタイムに暗号を解読し、改竄して再送信される危険性は少なくなる。悪意のある第三者がこれらを実行するには、「暗号化のキー（鍵）を入手しなければならない」からだ。 一方、すべて暗号化してしまえばいいじゃないかという声も出そうだが、そうもいかない。あらゆるデータを暗号化するにはどうしても計算能力が必要になるので、暗号化するサーバー側に負荷がかかり、運用コストの増大を招く。例えば、この記事は暗号化転送されていないが、それは暗号化する必要がないからだ。 これまでの話をまとめると、「通信を暗号化すること」ことで、途中では傍受されにくくなるということになる。しかし、それだけではインターネットの通信の安全を確保するには不十分だ。 ● 公開鍵暗号の1つ「RSA暗号」で共通鍵を受け渡す 最近「店屋物の出前」というシチュエーションはあまりないが、「宅配ピザを頼んだハズなのにラーメンが届く」といった事態は避けたい。この例を出したのは、インターネットの場合、相手が本当に接続しようとしてる相手か確かめにくいことを言いたかったからだ。出前のための電話は、電話会社が管理しているため、まず間違えることはないだろうが、インターネットの場合、偽情報でかく乱することは不可能ではない。偽情報でかく乱されないようにするためには、暗号化のための「共通鍵」をどうやって安全に受け渡すかが重要となる。共通鍵は、1つの暗号化のキーで暗号化と復号化（≒元に戻すこと）を行なうものだ。簡単に言えば、開ける鍵も閉める鍵も同じで、現実社会でよく使われている鍵と同じと思えばよい。 ただし、その鍵を持っていれば誰でも開け閉めができてしまうので、鍵を盗まれては困る。不正に入手された共通鍵が悪用され、「接続しようとしたら偽サーバーだった」「暗号化のキーを傍受されてすべて解読されていた」となってしまえば、共通鍵の意味がなくなってしまう。そこで登場するのが、「公開鍵暗号」だ。 公開鍵暗号の1つである「RSA暗号」は、サーバーが持つ「秘密鍵」で符号化したものは、一般に公開されている「公開鍵」でしか復号できない（誰でも入手可能な公開鍵で復号できるので暗号ではない。むしろ、暗号鍵を保有している証明と思ったほうがよいだろう）。一方、公開鍵で暗号化したデータは、秘密鍵でしか復号できない（ことになっている）。 つまりRSA暗号は、開ける鍵と閉める鍵がペアになっていて使うという特殊なタイプの鍵だ。公開鍵を使って扉を閉めてしまえば、秘密鍵でしか扉が開けられないというわけだ。なお、公開鍵暗号のすべてが「公開鍵で暗号→秘密鍵で復号」「秘密鍵で符号→公開鍵で復号」ができるわけではない。 ちなみに、オンラインショッピングやオンラインバンキングのサイトでは、「Webブラウザの右下に鍵アイコンがあることに注意しましょう」と書かれていることが多い。これは、ほとんどのブラウザでは、Webページで暗号化が行なわれると「鍵」アイコンを表示するためだ。 WebブラウザでのSSL通信はまず、やり取りに使用する共通鍵をクライアント側がランダムに生成し、これを公開鍵で暗号化してサーバーに渡し、サーバーは秘密鍵で復号化する。秘密鍵を持っているのはサーバー側だけなので、これで安全に共通鍵を渡すことができる。以降のデータのやり取りは、その共通鍵で暗号化すれば安全なやり取りが可能になる。 ● 公開鍵の正当性を証明するには では、公開鍵が本当にそのサーバーの公開鍵であるかどうかの保証は、どうやって判断するのだろうか？ もしかしたら、公開鍵が、なりすましの偽サーバーから出されているものかもしれない。そこで、Webサーバーが出す公開鍵に対しては、正当な鍵であるということを保証する「電子署名」が付与されている。これは、認証局（Certificate Authority：CA）が発行しているものだ。やり取りを行なっているはずのサーバー名と公開鍵に書いてあるサーバー名が同じで、さらに認証局の署名が正統ならば、その公開鍵は正しいことになる。 では、その「認証局が正しいことをどうやって証明するのか？」と堂々巡りになるが、一番上に「ルート証明書」というすべての信頼の根幹を成すものがあり、これはPCにあらかじめ入っている。ルート証明書の公開鍵で読めるものは、絶対の信頼があるという前提になっている。 ● 「信頼できるサイト」を実例で考えてみる
ユーザーは、インプレスダイレクトで申し込む場合、ある程度手続きが進むと暗号化ページに移行する。ページのプロパティを見ると、「direct.ips.co.jp」というサイトに接続しており、「SSL3.0」という方法で接続していることがわかる（「TLS1.0」を使う場合もある）。 暗号化は「RC4」という形式で暗号キーは128bit、RSA暗号は1024bitのキーを使っている。このため、サーバーとユーザー間のデータは暗号化されており、キーを知らなければ傍受はできないということがわかる。なお、プロパティを見なくてもInternet Explorer（IE）では右下に鍵アイコンが出ており、ここにマウスカーソルを当てて数秒待つと暗号ビット数が表示される。 なりすましはどうやって判断するのだろうか？ これを確認するのがサーバー証明書だ。IEでは右下に鍵アイコンが出ているはずなので、これをダブルクリックするとわかる。その証明書はdirect.ips.co.jpという相手が、「VeriSign Class 3 Secure Server 1024-bit CA」で2009年01月09日まで認定されていると書かれている。 このCA（認証局）は、ルート認証局となるVeriSign Class 3 Public Primary CAから認定されている。つまり、信頼の輪は切れておらず、direct.ips.co.jpのサイトが正しいことと、そのデータが改竄されていないという証明になる。証明書に書かれているドメインとアクセスしているドメインが異なる場合、証明書の有効期限が切れている場合、認証局のチェインが切れている場合などはページアクセスの前に警告ダイアログが表示されるが、マルウェアによって警告をしない設定に勝手に変更されてしまうこともよくある。設定が適切かこの機会に確認してみるのはどうだろうか？
今回の話は、ちょっと面倒な内容なので簡単にまとめると ・インターネットを安全に使うためには（共通鍵）暗号が必要 ・その共通鍵を安全に渡すためにRSA暗号を使う ・相手の公開鍵の正当性証明は認証局の電子署名で実現 の3つを扱った。RSA暗号の話を長くしたのは、このRSA暗号で共通鍵をやり取りするということはメール編でも同じ話をする予定だったのでまとめて行なった。次回は、「SSLなら安全なのか」という続きを行ないたい。 ● 先週の気になったニュース(3/10～3/16) ◆MS Accessの脆弱性突いたトロイの木馬が出現http://www.avertlabs.com/research/blog/index.php/2008/03/06/microsoft-access-exploits-nothing-new/ http://blog.trendmicro.co.jp/archives/1208 個人ユーザーだとAccessはあまり関係ないが、この形式（.MDB形式）のファイルは2004年に脆弱性が発見されているものの、マイクロソフトが危険なファイル形式とみなしているため、パッチが提供されていない。日本のユーザーを狙ったと思われる事例も出ているので、メールなどで届いたファイルを安易にクリックしないのが重要だ。 ◆RealPlayerのActiveXコントロールにパッチ未提供の脆弱性 http://internet.watch.impress.co.jp/cda/news/2008/03/11/18762.html 悪意のあるページを閲覧しただけで、RealPlayerの脆弱性によって任意のプログラムが実行される可能性がある。過去にもRealPlayerは何度もこの手の問題を起こしているので、アンインストールするというのも解決策と言いたくなるが、過去に紹介した手法でActiveXの実行を禁止しておくのがよいだろう。 ◆Amazon.co.jpの「ほしい物リスト」機能で名前が公開される http://internet.watch.impress.co.jp/cda/news/2008/03/12/18780.html 以前は「ウィッシュリスト」という名称で提供されていたが、いつの間にか名前が変わっている。ちょっとしたコードを埋め込むだけでAmazonから個人情報流出に近い被害が出るので、これは怖い。 ◆トレンドマイクロのウイルス情報ページが改竄、ウイルスを埋め込まれる http://internet.watch.impress.co.jp/cda/news/2008/03/12/18775.html http://internet.watch.impress.co.jp/cda/news/2008/03/13/18790.html 「紺屋の白袴」というか、「やっちまった」的な印象を受けるのだが、どのような問題から埋め込まれたのか詳細な後日レポートを期待したい（おそらく権限のあるIDのパスワードが「抜かれた」か「弱かった」のではないかと思う）が、大抵この手の詳細は明らかになることは少ない。「SQLインジェクションの可能性が高い」ということだが、SQLインジェクションを防ぐサイト構築術というのも以前から言われている話だ。 ◆18歳未満の半数以上「フィルタリング解除のために親に同意求める」 http://internet.watch.impress.co.jp/cda/news/2008/03/13/18802.html 筆者的には、「守れないフィルタリング」は無意味で、現在の基準は厳し過ぎると思う。もう少しレベル分けのされたフィルタリング（小学生は見れないが中学生ならよい、とか）が必要なのではないだろうか？ なお、ソフトバンクの場合、メールはできるがWebは不可能という契約もある（通常契約だと裏ワザだが、プリペイドという手もある）。 ◆アフィリエイトのクリック水増しに加担するトロイの木馬が出現 http://www.symantec.com/enterprise/security_response/weblog/2008/03/trojantrafbrush_providing_a_cl.html 設定ファイルを自動更新して、アフィリエイトクリックを自動的に行なったり、キーワード検索を行なう。割と考え付きそうなことだが、実際に（トロイの木馬を作って）やるとは。後者の行為は、他社の広告予算をムダに削る妨害工作だろうか？ 2008/03/19 11:39
- ページの先頭へ-
|
