烏山 雄大，新井 一人，坂 恵理子
「オフレコ」で「プライベート」なコミュニケーションとは
安全なコミュニケーションの手法としては，PGPなどを使った暗号化が一般的である。しかし，「オフレコ」で「プライベート」なコミュニケーションに，はたしてPGPが適しているのだろうか。Ian Goldberg氏は「Off-the-Record Messaging（Or，when not to use PGP）」という講演で，こう問いかけた。Goldberg氏は，「オフレコ」で「プライベート」な場合，PGPには「鍵を盗まれた場合に安全性を確保できない」「事後否認ができない」といった問題点があると指摘した。そして，表11[拡大表示]に示した三つの課題を実現することがゴールだとした。
|
| 表11 「オフレコ」で「プライベート」なコミュニケーションを実現するためにGoldberg氏が指摘した課題 |
Perfect Forward Secrecy
一般に，暗号鍵を盗まれた場合，過去のメッセージの安全性は確保できない。しかし，鍵が盗まれたことを発見して修正すると，それ以上は過去のメッセージが漏えいしないという仕組みを作れば成立する。実現するには，(1)過去のメッセージに使用した過去の暗号鍵はコンピュータの中のいかなる情報からも導き出せない，(2)鍵を定期的に更新する，ようにしておく必要があると言う。
この対策に必要なコストは，使用している暗号の方式に依存する。RSAなどの公開鍵暗号方式を使用している場合は高価だが，EL CamalやDeffie-Hellmanなどなら安価である。
では，本当に鍵を定期的に変更するだけでよいのだろうか。この問いに対する答えは「ノー」である。なぜなら，このために多大な管理を要するからである。新しい鍵を配布するコスト，古いものを管理するコストが必要になる。新しい鍵を配布する際には，相手の鍵がどれか，相手に対する鍵はどれがよいのか，過去の鍵ペアはどれかを覚えておく必要がある。
この煩雑な管理の解決策としては，Goldberg氏は(1)メッセージを送付する際に現在の鍵を使ってロックする，(2)返信する際に新しい鍵を生成し送付する，ことで対応可能だとした。しかし，この方法は新規の鍵の生成，鍵ペアの管理が自動化できない限り，非現実的である。
Message Authentication Code
「オフレコ」であるがゆえに，完全性を確保しながら「事後否認が可能」を考える。
そこで，作成者本人が書いたものが改ざんされていないことを確認する方法として，Message Authentication Code（MAC）を使用する。MACはシンメトリック暗号を使用した公開鍵暗号署名である。送信者と受信者はMACキーを共有し，第三者は模倣できない。
Malleable Encryption
事後否認を可能にする方法として展性暗号を使用する。具体的には，ブロック暗号でXOR演算を使用する，または，RC4などのストリーム暗号を使用するなどの方法がある。
ここで問題になるのはMACを使用する意義である。「オフレコ」の通信で確認すべきは，受け取った時の送信者の署名であり，第三者が後で改ざんしたかどうかは問題ではない。
「オフレコ」「プライベート」といったコミュニケーションが本当に必要かどうかは疑問だが，安全なコミュニケーションの一つの方法として，認識すべきものと思われる。
開発ベンダのセキュリティ意識を糾弾
Loveletterウイルスが85億ドルもの損害を出したのは記憶に新しい。このウイルスの被害は「米MicrosoftのOutlookの仕様が原因」とHoglund氏は「Application Security（Fixing Bad Software）」という講演において言い切った。つまり，「アプリケーションのセキュリティとは，ソフトウエア自身の品質そのもの」だと指摘した。
Bad Softwareとは
|
| 表12 Hoglund氏が定義した「Bad Software」 |
例えば，バッファ・オーバフローは15年前から既知の問題と認知されている。にもかかわらず，いまだに同様のミスが起こっている。開発側の責任は拭いきれるものではない。安全性にかかわる致命的な問題が発見された場合，ほかの業界では消費者はだまってはいない。裁判沙汰になる場合もある。しかし，ソフトウエア業界は出荷開始を優先するために，バグ修復を延期し，後でパッチを提供すればよいと思っている。
プログラム1000行につき5～50のバグ
接続するプロトコルが増え，サポートするデバイスが多様化すると，コードも複雑化する。これも大きな原因である。例えば，Microsoft Wordは1983年当時，2万7000行のコードで作成されていたが，その後コード・サイズは急激に増加した。代表的なソフトウエアを例に挙げると，Solaris7は40万行，Netscapeは1700万行，Linuxは150万行ものコードから成る。Hoglund氏は「プログラムは1000行につき5～50のバグを抱える」と言う。つまり，最近のソフトウエアは常に“血まみれ”なのである。実際，Windows 2000は6万3000もの既知のバグを抱えたまま出荷開始されたという。
ベンダのセキュリティへの対応が遅れている主な理由はコストである。しかし，最大の問題はベンダが深刻に考えていないことだ。ハードウエアの場合，バグを修復するコストは高い。このため，リリース前に十分なテストを実施する。実際に米IntelのF00Fバグはリプレースに5億ドルがかかった。しかし，ソフトウエアのバグはパッチを出せば，Webサイトからダウンロードできる。顧客が修復コストを払ってくれる。
ただ，同氏は今回の講演において，このような開発者側の問題点を指摘しながら，「Bad Software」を購入する消費者自身にも責任があるとした。消費者側の問題は「大手メーカが発売したソフトは安全で信頼性が高い」と考えがちなことだという。大手メーカのソフトウエアという理由で，安易に購入する消費者にも問題があるというのだ。ただ半面で，消費者の側には，新機能を安全に搭載した新バージョンの発売まで2年も待てるのか，10倍の値段を払うことができるか，という問題も存在する。
最近はMicrosoftがセキュリティを重視した開発方針に打ち出した。開発ベンダの意識が変わり，ソフトウエアの安全性が向上することが望まれる。
レイヤ2スイッチのセキュリティ対策
「Hacking Layer 2：Fund with Ethernet Switches」の講演では，米Cisco SystemsのSean Convery氏が，Ciscoと米＠Stakeのテストしたレイヤ2スイッチに対する特定の攻撃と対処方法を説明した。前提としたのは「内部による不正アクセス」である。
一般に，下層のレイヤが侵害されると，それは上位レイヤも侵害されることにつながる。このためレイヤ2のセキュリティは重要だ。しかし，レイヤ2のセキュリティは意外と考慮されていない。例えば，以下の質問に何と答えるだろうか。
Q レイヤ2のセキュリティについてどのように考えているか
Q VLANをよく使用するか
Q VLANを使用し，かつ同じスイッチに異なるセキュリティ・レベルを設けたことはあるか
Q セグメントの割り当てのプロセスは
通常のネットワーク管理者はレイヤ2にセキュリティ問題があるとは考えていない。セキュリティ管理者でも，注目はレイヤ3以上である。VLANを使っていても，組織内のどの個所で実際に使用しているかを認識していない場合が多い。
|
| 表13 Convery氏が指摘したレイヤ2スイッチに対する代表的な攻撃 |
まず，ネットワーク管理者はsyslog，SNMP，TFTP，Telnet，FTPといったネットワーク管理プロトコルが安全でないと認識し，プロトコルの安全性が確認されているSSH，SCP，SSL，OTPなどを使用べきだという。これらのプロトコルが使用できない場合は，OOB（Out of Band）管理方法を検討することとしている。OOBとは，別のVLANセグメントを作成し，そのセグメントには管理用パケットを流さないようにすることである。OOBも不可能な場合は，管理プロコルに対して「set Ippermit」を設定し，アクセル制御することを勧めるという。
|
| 表14 Convery氏が提唱したレイヤ2スイッチのセキュリティ管理法 |
このレポートで紹介したのは，あくまでも講演の一部である。このほかにも，セキュリティに馴染みの薄い受講者に対してQ＆A形式で説明する講演，実際の攻撃例を示しながら防御手段をHow to形式で教授する講演，サーバー構築したりサービスを提供する際に陥りやすいセキュリティ上の問題点を挙げながらセキュリティ・レベルの高いサーバー作成する講演などがあった。
BlackHatは，これら防御に必要な知識がふんだんにつまった上質の会議である。初めにも言ったが，一度参加することをお勧めして，レポートを終えたいと思う。
| 烏山 雄大，新井 一人，坂 恵理子 筆者は三井物産のセキュリティ・チームGTI PROJECT CENTERに勤務。セキュリティ・コンサルタントとして企業のシステム構築を支援している。ここ数年，毎年BlackHat Briefings USAに参加している。 |
