なぜ暗号化は役に立たなかったのか
米最大規模の情報流出事件を検証
2007/04/03
米小売大手のTJX Companiesで起きた過去最大規模の顧客情報流出事件は、暗号化が特効薬でないことを示した。
以下は、TJXが証券取引委員会に提出したフォーム10-K報告書の抜粋であるが、これは暗号化をめぐる問題の核心ともいえるものだ。
「フレーミンガムのシステムには、2006年にマスキングおよび暗号化対策を実施したが、2006年のコンピュータ侵入で利用された技術は、支払いカード発行者の承認プロセスの最中にフレーミンガムのシステムから支払いカードのデータを盗むことを可能にした。この承認プロセスでは、データ（トラック2のデータを含む）が暗号化されないまま支払いカードの発行者に送信される。さらに、TJXで利用していた暗号化ソフトウェアの復号化ツールにも侵入者がアクセスしていたと考えられる」
暗号化技術があってもデータが暗号化されなければ何の価値もないのは当然だが、クレジットカード番号が暗号化されたままだとカードを処理することができない。それゆえ、ずる賢い悪党は、データが「裸の」（つまり暗号化されていない）状態にある瞬間を狙ってそのデータを入手しようとするのだ。
TJXへの侵入者は、裸のデータが入手できない場合に備えたバックアップ対策（すなわち復号化キー）も用意していた。
規制当局が暗号化技術の使用をどれだけ強く要求しようとも（あるいは要求したいと考えていても）、TJXで暗号化が役に立たず、また多くの企業で暗号化が役に立たない可能性があると思われる理由はいくつかある（暗号化に関する当局の指令の例としては、連邦政府機関が保有するすべてのノートPCおよびモバイルデバイスのHDDを暗号化するよう求めた2006年6月のホワイトハウス指令がある）。
マカフィーの最高セキュリティ責任者 マーティン・カーマイケル博士は米eWEEKの取材で、「この侵入事件に関するTJXの見解を読めば、同社が暗号化技術を使っていたのは明らかだが、具体的にどんな種類の暗号化方式が用いられたのかが分からない。暗号化されたデータの送信者と受信者が同じ鍵を保持する共有鍵方式なのか、それとも公開鍵と秘密鍵のペアを使用する非対称方式なのかは不明だ」と述べている。
共有鍵暗号方式は本質的にリスクが大きい。人々は、鍵を保管するのに便利だけれども途方もなく危険な場所を考え出すからだ。
「ほとんどのセキュリティポリシーで許されない」
「鍵とデータを一緒に保管する共有鍵暗号方式を使っている企業もある。これはほとんどのセキュリティポリシーで許されないことだ。開発が容易であるということが、優れたセキュリティプロセスと対立することもある」とカーマイケル氏は語る。同氏は実際に、「データの鍵」という名前が付けられたファイルに鍵が含まれているのを見たことがあるという。
暗号化をめぐるもう1つのわなが、弱い暗号の使用である。当初のDES（Data Encryption Standard）暗号化は、現在では多くのアプリケーションにおいてセキュリティが不十分だと考えられている。これは主として、鍵のサイズが56ビットというのは小さすぎるという理由によるものだ。DESの暗号鍵が24時間以内に解読されたこともある。また、暗号自体の論理的弱点を指摘する分析結果もあるが、これについては実際に証明されたわけではない。
2002年5月、公開入札の結果に基づき、DESはAES（Advanced Encryption Standard）に取って代わられたが、2004年の時点でも、DESはまだ広範に利用されていた。カーマイケル氏によると、DESは「多くのアプリケーションで非常に一般的だった」という。
TJXはDESを使用していたのだろうか。TJXでは、同社のデータが最初に不正な侵入者にアクセスされたのは2005年7月だと断定している。DESが2004年に広く利用されていたことからすれば、同社もDESを使用していたと推測される。
非対称型暗号化は、鍵の一部をデータの送信者に与え、別の一部を受信者に与えるという方式。データの受信者（例えば、ユーザーの銀行口座番号、ユーザー名、個人識別番号などを受信する銀行）は、鍵の公開部分を一般に公開することができる。しかしデータを暗号化するのは、鍵の非公開部分だけである。銀行の顧客は一方の鍵を使って銀行にアクセスし、銀行は自分たちが持っている鍵を使って照合することができる。このように、2つの異なる鍵を使って暗号化セッションが行われるのである。
鍵の保管でセキュリティの不安
カーマイケル氏によると、この種の公開鍵／秘密鍵暗号が用いられるのは、鍵の配布が重要な問題であるからだという。共有鍵はどこかに保管しなければならない。しかしどこに保管しようとも、セキュリティの不安が付きまとう。
公開鍵／秘密鍵暗号を利用する企業は、秘密鍵を「非常に特別な場所」に保管する、とカーマイケル氏は話す。その場所とは、堅牢なセキュリティを備えた認証サーバである。
TJXの侵入者は、共有鍵方式で暗号化されたデータと一緒に保存されていた鍵を偶然見つけたのだろうか、それとも認証サーバにアクセスするのに成功したのだろうか。
侵入者が暗号化される前のデータを取り出す手段を考え出したことからすれば、この疑問の現実的意味はないが、TJXでの調査が今後も続けられ、暗号鍵の盗難の詳細が明らかになれば、貴重な教訓が得られるであろう。
パフォーマンス低下が妨げになることも
結局、われわれには非対称型の（すなわち公開鍵／秘密鍵による）暗号化という選択肢しか残されていないわけだが、この方式の暗号化は特効薬といえるのだろうか。共有鍵暗号と比較すれば間違いなくそうだが、逆効果になる危険性もある。
Application Securityの戦略担当副社長、テッド・ジュリアン氏はeWEEKの取材の中で、「暗号化の利用を考えているユーザーにとって常に現実的な問題となるのが、パフォーマンス面でのオーバーヘッドだ」と話している。実際、この問題が契約成立の妨げになることも多いという。
パフォーマンスが低下するのは、非常に多くアプリケーションがインデックスフィールドでセンシティブなデータを使用するからだ。ジュリアン氏は一例として、大学生の社会保障番号を大学でのID番号として使用するという以前の一般的な慣習を挙げた。成績であれ学費納入記録であれ、特定の学生の情報を調べるには、インデックスフィールドに対してクエリを実行しなければならない。
しかしそのフィールドには社会保障番号というセンシティブなデータが含まれているため、大学側はそのフィールドを暗号化しようと考えるようになる。「しかしそうなると、システムのパフォーマンスが大きくダウンする」とジュリアン氏は指摘する。
「Oracle Database 10g R2に搭載されたネイティブ暗号方式であろうとなかろうと関係ない。このパフォーマンス低下は受け入れ難いものだ」（同氏）
アプリケーションが壊れる可能性
このような状況を避けるには、すべてのアプリケーションを変更し、異なるインデックスフィールドを使用するようにする必要がある。これは大変な作業だ。それに、この作業によってアプリケーションが壊れないという保証はない。
同様に重要なもう1つの問題は、公開鍵／秘密鍵暗号化にはアーキテクチャが関係するということだ。その際に考慮すべき問題は、鍵の強度をどの程度にするか、鍵をどこに保管するか、誰がアクセスできるようにするかなど多岐にわたる。
「これらの問題はいずれも、超一流の科学者が何人もいないと解決できないというものではないが、専門知識は必要だ。それに間違いは許されない。ラボでテストを行うとともに、効果的に機能することを確認する必要がある。また、セキュリティポリシーと連携するように組織の各部門を参加させることも必要だ」とジュリアン氏は話す。
そしてここでもアプリケーションへの影響という問題がある。これまで裸の状態のデータを扱ってきたアプリケーションが、暗号化されたデータを処理しなければならなくなるのだ。
ジュリアン氏によると、こういった負荷の変化がアプリケーションを壊すことは「十分にあり得る」という。大量のデータが入力されるのを想定していないアプリケーションでは、バッファオーバーフローが容易に引き起こされる可能性がある。
「アプリケーションが遅くなる可能性があるが、これはトライアル版を作成し、ラボでテストをするまで分からない。本番環境をシミュレートして動作状況を確認した上で、徐々にアプリケーションを配備する必要がある。これは半年から1年に及ぶプロセスだ」とジュリアン氏は語る。
しかも同氏によると、それぞれのアプリケーション、つまり過大な負荷で壊れる恐れがあるアプリケーションごとに、それだけの期間が必要になるという。
データベースのモニタリングシステム
暗号化技術を採用すべきかどうか迷っている企業や、TJXの二の舞を避ける方法を模索している企業にとって望みはある。ジュリアン氏によると、暗号化システムをセットアップするのにかかるよりもずっと短い時間で、はるかに効果的なセキュリティ対策を講じることができるという。
その方法とは、データベースの脆弱性評価を行い、稼働中のデータベースのモニタリングシステムをセットアップすることだという（関連記事）。
脆弱性評価作業には、デフォルトのIDやパスワードをそのまま使っていないかチェックするといったことが含まれる、と同氏は話す。このような状況は決して珍しくはないという。また、既知の脆弱性の有無を確認する、パッチを適用する、攻撃に対してデータベースを堅牢化するといった作業も含まれる。これらの対策により企業は「1日で相当な改善を実現する」ことができる、とジュリアン氏は話す。
データベースの稼働状況のモニタリングは、データベースを狙う攻撃者に対する注意を企業に喚起するだけでなく、信頼できる従業員が是認されていない操作を実行しようとした場合も注意を喚起する。例えば、データベース管理者といえども、クレジットカード番号の列に対して「select-*」を決して実行すべきではない。
これらの2つのステップ――データベースの評価とモニタリング――は、「データベースのセキュリティ体制を大幅に改善する可能性がある」とジュリアン氏は話す。「しかもこれは、まだ暗号化を導入する前の段階なのだ」
TJXでは暗号化対策も役立たなかったようだ。「絶対確実なものは何もないのが、TJXの場合は明らかにモニタリングが有効であるようだ。この対策を講じていれば（流出した）4750万件のクレジットカード情報が画面に表示されていたかもしれない。ただし、画面を監視していることが前提だが」（ジュリアン氏）
（eWEEK Lisa Vaas）
関連記事
Copyright(c) eWEEK USA 2002, All rights reserved.
情報をお寄せください：
最新記事
 |
|
|
|
|
