Lavabit 事件とその余波、そして Forward Secrecy

Lavabit事件

Lavabitという名前をみなさんご存知だろうか。NSAの監視活動について内部リークを行った Edward Snowden氏が利用していたメールサービスとして今年の夏に一躍有名になったところだ。Snowden氏は香港に滞在して複数のジャーナリストにNSAの内部情報を提供したあと、現在はロシアに一時亡命しているが、亡命が認められる前にモスクワ空港にしばらく滞在していたことがある。7月12日に空港内でプレスカンファレンスを行ったのだが、その時複数の人権団体に送った招待状が “edsnowden@lavabit.com” というメールアドレスからだった。この事が報道されると、「あの」Snowden氏が使っているメールサービスということで、利用希望者が殺到したらしい。(それまで新規登録は 200人/日だったのが、4,000人/日と20倍になった。)

しかしそんな表の騒動の影で、裏では Lavabitと FBIとの間でバトルが繰り広げられていた。Snowden氏によるリークの報道がはじまったのは 6月だが、実はその前の 5月から FBIは Lavabitのオーナーである Ladar Levison氏に接触していた。そして Snowden氏は内部告発者として 6月9日に名乗り出たが、その翌日の 6月10日には Lavabitに対して Snowden氏のアカウント*1に関する情報 (住所や氏名などの個人情報、IPアドレスやメールの送受信ログなど、ただしメールの中身は含まない) を要求する裁判所命令が出されている。Levison氏は命令に従い、1日1回これらの情報を FBIのサーバにアップロードして対応した。しかし FBIの要求はさらにエスカレートし、Snowden氏のアカウントのメール送受信をリアルタイムに盗聴できるようにすることや、当局が暗号化されたデータを復号するために SSL秘密鍵などの提出を命令してきた。Lavabitのユーザはこの時点で 40万人に増えていたが、Levison氏はこれら全ユーザのプライバシーを危険にさらすことから命令に従うことを拒否。しかし裁判所は Levison氏の主張を聞きいれてはくれなかった。ここで Levison氏は奇策にでる。秘密鍵の提出方法が指定されていなかったことから、複数あるSSLの秘密鍵を OCRで読み取ることができないように 4ptで印刷した11ページのプリントアウトで提出した (図1)。しかし電子データで提出しないと1日あたり $5,000の罰金を課せられることになり万事休す。Levison氏はやむなく秘密鍵を提出し*2、その2日後の 8月8日にサービスの終了を発表した*3。サービス停止を発表した際の Levison氏のコメント「アメリカ市民への犯罪行為に加担するか、10年も続けてきた Lavabitのサービスを終了するか、非常に難しい決断をせまられた」には、苦悩のあとが伺える。

サービス終了時の Lavabitから顧客へのメッセージ (2013-08-08)

I have been forced to make a difficult decision: to become complicit in crimes against the American people or walk away from nearly ten years of hard work by shutting down Lavabit. After significant soul searching, I have decided to suspend operations. I wish that I could legally share with you the events that led to my decision. I cannot. I feel you deserve to know what’s going on--the first amendment is supposed to guarantee me the freedom to speak out in situations like this. Unfortunately, Congress has passed laws that say otherwise. As things currently stand, I cannot share my experiences over the last six weeks, even though I have twice made the appropriate requests. (下線は筆者による)

(図1) Levison氏が提出した SSL秘密鍵の一部。(注：一度印刷されたものをスキャナーで読み込んでいるので、元の資料よりさらに読みにくくなっている。)
公開された裁判所の資料はココから読める。

この事件はさまざまな影響を及ぼしたが、一つは Silent Circle*4もメールサービス (Silent Mail) を終了すると8月9日に発表したことだろう。Silent Circleは Lavabitのサービス終了の状況を見て、もし同様のことが自分達に起こった場合、ユーザのプライバシーを保護することができないと判断したようだ (Silent Circleのブログ参照)。

もう一つは SSLの秘密鍵に関することだ。Levison氏はその後のインタビュー等で、Lavabitで Diffie-Hellmanをサポートするべきだったと話している。これは何のことを言っているのだろうか? それが次の話題の Forward Secrecyである。

ちなみに Lavabitと Silent Circleは 10月30日に DarkMail Allianceの立ち上げを発表した。来年を目処に現在の古くてセキュアではないメールプロトコルに代わる新しいプロトコルを XMPPベースで開発することを目指している(彼らは ‘Email 3.0’と呼んでいる)。こちらの動きにも今後要注目だろう。

Silent Circle and Lavabit launch “DarkMail Alliance” to thwart e-mail spying | Ars Technica (2013-10-30)

“Knowing that they’re coming after SSL keys—for starters I would have made sure that all my systems support Diffie-Hellman,” he said. “The recent addition that provides an extra exchange for a negotiation process that makes it impossible to find out the session key, even if [the authorities] have the private key. It effectively would have forced them to do a man-in-the-middle attack instead of a third-party eavesdropping. It also means that if you’re forced to turn over keys in the future, they wouldn't be able to go back and decipher.” (下線は筆者による)

Announcing The Dark Mail Alliance – Founded by Silent Circle & Lavabit | Silent Circle Blog (2013-10-30)

Silent Circle and Lavabit, as privacy innovators have partnered to lead the charge to replace email as we know it today – fundamentally broken from a privacy perspective – we have collaborated in developing a private, next-generation, end-to-end encrypted alternative.

Forward Secrecy

ブラウザが Webサーバと TLS/SSLで通信を行う場合、セッション毎に異なる暗号鍵が生成されるが、クライアントとサーバが同じ鍵を共有するために最初に鍵交換のプロセスが必要になる。現状最もポピュラーな鍵交換の方法は RSAを利用したものだろう (ここでは RSA鍵交換とよぶことにする)。この場合、クライアントが生成した 48byteの Premaster SecretがサーバのRSA公開鍵 (最初にサーバから送信されるサーバ証明書に含まれる)で暗号化されてサーバに送信される。サーバは自身のRSA秘密鍵でこれを復号し、互いに共通する Premaster Secretが手に入る。これを Master Secretに変換して、暗号鍵の生成に利用する。

RSA鍵交換の問題は何かというと、すべてのセッションにおいて Premaster Secretの暗号化に同じ鍵 (サーバのRSA公開鍵) が利用されるという点である。ここで WebサーバのSSL通信をすべて盗聴できる攻撃者がいたと仮定しよう (NSAがまさにこの攻撃者に該当する)。この攻撃者はサーバの秘密鍵を持っていないので、盗聴した暗号通信を復号することはできない。しかし将来なんらかの手段によって攻撃者がサーバの秘密鍵を入手できた場合、この攻撃者はそれまでに保存したすべての暗号通信を復号して見ることができてしまう。

この問題は20年前からすでに知られており、鍵交換プロトコルが備えるべき性質のひとつとして Forward Secrecy (または Perfect Forward Secrecy、FSや PFSなどと省略する) が挙げられていた。

Authentication and Authenticated Key Exchanges

Perfect Forward Secrecy
An authenticated key exchange protocol provides perfect forward secrecy if disclosure of long-term secret keying material does not compromise the secrecy of the exchanged keys from earlier runs. The property of perfect forward secrecy does not apply to authentication without key exchange.

WebサーバのSSL秘密鍵など比較的長期間にわたって使用される鍵が外部に漏洩したとしても、それ以前のセッションにおいて利用された暗号鍵にはなんの影響も及ぼさない、というのが FSの性質だ。さきほどの RSA鍵交換はこの性質を満たしていない。つまり FSを達成できない。
一方、Ephemeral Diffie-Hellman鍵交換 (EDHまたは DHE) は FSを達成できる。セッション毎に鍵交換に必要なパラメータを生成し、クライアントとサーバがそれぞれ計算した値を交換することにより共通の Premaster Secretを生成する。このときサーバの秘密鍵 (RSAまたはDSA) はサーバから送信されるDHパラメータの署名にのみ使用され、暗号化には使われない*5。また楕円曲線暗号を利用した Diffie-Hellman鍵交換 (ECDHE) も DHEと同様に FSを達成できる*6。
(注: サーバ証明書に DH公開鍵が含まれている場合、その固定パラメータを使って鍵交換を行なうことができる。しかしこの場合にはRSA鍵交換と同じで FSは達成できない。またこのタイプの証明書は現在ほとんど使われていない。TLS/SSLでは DH_RSA, DH_DSSによる鍵交換がこれに該当する。また ECDH_RSA, ECDH_ECDSAも同様。)

	鍵交換方式	サーバ認証	FS (PFS)
RSA鍵交換	RSA	RSA	×
DHE鍵交換	DHE	RSA or DSA	○
ECDHE鍵交換	ECDHE	RSA or ECDSA	○

RSA鍵交換の場合、サーバの秘密鍵が漏洩する (または鍵が解読される) とすべてのセッションが復号できてしまうのに対して、DHE/ECDHE鍵交換であればセッションを復号するためにはそれぞれセッション毎の暗号鍵を解読する必要がある。NSAによる包括的な監視が行われている実態が明らかになったことを考えると、通信データの機密性がサーバの秘密鍵だけに依存するのはなんとも心許ない話だ。もし Lavabitが FSに対応していれば、つまりDHE/ECDHEによる鍵交換をサポートしていれば、たとえサーバの秘密鍵を当局に渡したとしても各ユーザのセッションを復号されることはなかったはずだ。(ただしこの場合、FBIは Lavabitのサーバになりすますことができるので MITMは可能。)

Forward Secrecy への対応状況

Webでの通信においてFSを実現するには、ブラウザ等のクライアントとWebサーバの双方で対応する必要がある。ではこれらのFSへの対応状況はどうなっているのか。2つのデータを紹介しよう。

1つめは Netcraftが今年の 6月に公表した調査データ。約240万の SSLサイトに対して 5種類の主要なブラウザ (Firefox, Chrome, Opera, Safari, IE) でアクセスした結果、およそ 2/3は FS対応の暗号スイートを利用していなかった。ブラウザ別では特に IEの成績が悪くなっているが、これは他のブラウザが FS対応の暗号スイートをFS非対応のものより優先しているのに対し、IEはそうではないためである。また DHE_RSAに対応した暗号スイートを IEはサポートしていない。
一方で Webサーバ側が FSに対応していないのは、DHE鍵交換の処理が重くパフォーマンス的に不利になるためだと考えられる。しかし比較的新しい ECDHEでは処理速度が早くなっており、RSA鍵交換との差は縮まっていると言えるだろう。

Netcraftの発表内容
http://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html
http://www.netcraft.com/internet-data-mining/ssl-survey/

2つめは Qualysが公開している SSL Pulseの調査データ。直近の 10月のデータによると、約16万サイトを調査した結果、54%のサイトが FSに対応していなかった。しかし FSに対応しているサイトのほとんども対応は不十分で、多くのブラウザとの通信において FS対応の暗号化スイートが使われていない。これはサイト側が ECDHEに対応していないためだと思われる。その結果、全体の 95.8%で FSが使われていないという状況になっている。

Qualysの発表内容
https://community.qualys.com/blogs/securitylabs/2013/10/09/ssl-pulse-now-tracking-forward-secrecy-and-rc4
https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy

主要なサービスの対応状況

こういった取り組みにいつも先行するのはやはり Google。2010年に他のサービスに先駆けて GmailのデフォルトHTTPS対応をはじめたが、2011年には Gmailなどの主要なサービスで FSにも対応している。

Google Online Security Blog: Protecting data for the long term with forward secrecy (2011-11-22)

Last year we introduced HTTPS by default for Gmail and encrypted search. We’re pleased to see that other major communications sites are following suit and deploying HTTPS in one form or another. We are now pushing forward by enabling forward secrecy by default.

Facebook, Twitter, Yahoo!, Apple, Microsoftなどのサービスでは 6月の時点では主要なブラウザにおいて FSは利用されていなかったようだが、その後 Facebookと Twitterは対応するようになった。おそらく今後他のサービスでも対応がすすむと考えられる。ちなみに日本の状況はどうかというと、Yahoo! Japan、楽天、mixiなどはまだどこも FSに対応していない。

(例) Chromeでアクセスした際に使われる鍵交換の方法 *7

Google	Facebook	Twitter	Yahoo!	Apple	Microsoft	Yahoo! Japan	Rakuten	mixi
ECDHE_RSA	ECDHE_RSA	ECDHE_RSA	RSA	RSA	RSA	RSA	RSA	RSA

(図2) Googleに Chromeでアクセスした場合

(図3) Yahoo! Japanに Chromeでアクセスした場合

まとめ

以上、Lavabit事件とその影響、Forward Secrecyへの対応状況などについて紹介した。今後は主要な Webサイトにおける FS対応がさらに進むことが予想される。なお Forward Secrecyはなにも TLS/SSLに限定した話ではなく、メッセージングの世界でも対応がすすんでいる。次回はこの話題 (OTR: Off-the-Record Messageing) について取り上げる予定。予定は未定。

(参照)
Edward Snowden’s E-Mail Provider Defied FBI Demands to Turn Over Crypto Keys, Documents Show | WIRED
As F.B.I. Pursued Snowden, an E-Mail Service Stood Firm | NYTimes
Edward Snowden has applied for asylum in Russia: Russian media (LIVE BLOG) | GlobalPost
SSL/TLS & Perfect Forward Secrecy | Vincent Bernat
Geekなぺーじ:スノーデン事件の裏で起きていたSSL秘密鍵を巡る戦い

*1:裁判所から公開された資料では個人情報がマスクされているが Snowden氏のアカウントだと考えられている。

*2:Lavabitのサーバ証明書は GoDaddyが発行したものだが、この事件が報道されるとすぐに証明書を無効にしている。https://lavabit.com/ を参照。

*3:この時点では gag orderによりサービス停止の理由について Levison氏は一切しゃべることができなかった。事件の概要がわかったのは 10月になって裁判所が機密指定を解除してから。

*4:PGPの開発者である Phil Zimmermann氏が共同創業者の一人である。

*5:サーバから送信される ServerKeyExchangeメッセージで署名された DHパラメータが送信される。RSA鍵交換では ServerKeyExchangeは送信されない。

*6:TLS/SSLで FSに対応している鍵交換の方式は DHE_DSS (EDH_DSS), DHE_RSA (EDH_RSA), ECDHE_RSA, ECDHE_ECDSA の4つである。

*7:Version 32.0.1685.0 dev版を使用して 11月3日に調査した結果。

(続) Facebookのパスワードリセット機能のまとめ

前回の記事では、複雑な Facebookのパスワードリセット機能についてまとめてみたのですが、引き続き調べてみるとおもしろいことがわかってきました。ということで続編です。(割とどうでもいいような細かいことが気になるんですよね。)

まずは前回の復習。私が知っている限り、Facebookは次のような方法でパスワードをリセットをすることができます。

1. 通常の方法
 1-1. Googleアカウントでログインする
 1-2. 登録しているメールアドレスにメールで確認コードを送る
 1-3. 登録している携帯電話に SMSで確認コードを送る
 1-4. コードジェネレータを利用する
2. 「セキュリティのための質問」に回答する
3. 友達の助けを借りる
 3-1. 「信頼できる連絡先」を事前に登録している場合
 3-2. 「信頼できる連絡先」を登録していない場合

前回の記事を書いていたときには、(2) と (3-1)、そして (3-1) と (3-2) はそれぞれ排他的であり、両方同時に有効になることはないと思いこんでいました。まあ普通に考えたらそうですよね。ところが実際には両方とも有効なアカウントが存在することがわかりました。驚愕の事実です。(こちらの記事にも間違いがあったので訂正してあります。)

そうなると一体どういうパターンが存在するんだと気になってきました。しかし個別のアカウントの設定項目を調べるだけでは限界がありますし、パスワードリセットのオプションがどういう条件で使えるようになるのかもはっきりしません。そこでいくつかのアカウントについて、パスワードリセットのどの方法が有効になっているのか具体的に調べてみることにしました。

(1)の通常の方法はどのアカウントでも利用できます。そうするとパターンとしては (2)、(3-1)、(3-2)の 3つのオプションがそれぞれ使えるか使えないか、全部で 8通りになるはずです。

パターン	(1) 通常	(2) SQ	(3-1) TC	(3-2) GH	補足
パターン1	◯	×	×	×	SQもTCも未設定の状態。最近登録したアカウントのデフォルト。
パターン2	◯	◯	×	×	SQを設定した状態。
パターン3	◯	×	◯	×	TCを設定した状態。
パターン4	◯	◯	◯	×	SQとTCを両方とも設定した状態。
パターン5	◯	×	×	◯	パターン1との違いが生じる条件が不明。登録時期や設定内容によると推測。
パターン6	◯	◯	×	◯	パターン2との違いが生じる条件が不明。登録時期や設定内容によると推測。
パターン7	◯	×	◯	◯	パターン3との違いが生じる条件が不明。登録時期や設定内容によると推測。
パターン8	◯	◯	◯	◯	パターン4との違いが生じる条件が不明。登録時期や設定内容によると推測。

(SQ: Security Question, TC: Trusted Contacts, GH: Get Help From Friends)

Facebookの中の人でもない限り、これらのパターンがどの程度存在するのかなんてわかりません。しかしそもそも存在するのかしないのかくらいは、身近なところで調べればわかりそうです。というわけで、Facebookのお友達の中から適当に 100人選択して、上記のどのパターンに該当するのか調べてみました。結果は次のとおりです。

パターン	該当人数
パターン1	17
パターン2	43
パターン3	1
パターン4	5
パターン5	10
パターン6	21
パターン7	1
パターン8	2

調べたアカウントには当然偏りがありますし、数字そのものに特に意味はありません*1。しかしパターン8 (すべてのオプションが有効) という人がいたり、思っていたよりも (3-2) のオプションが有効な人 (パターン5, 6, 7, 8の 34人が該当) が多いことや、全部のパターンが存在するということがわかり、個人的には非常に興味深い結果が得られました。またこれは私の友達に限ってのことかもしれませんが、「セキュリティのための質問」を多くの人 (71人) が設定している一方、まだ比較的新しい機能である「信頼できる連絡先」を設定している人 (9人) は少ないですね。

みなさんも自分の Facebookアカウントが上記のどのパターンに該当するのか、ぜひご自身で確認されることをオススメしたいと思います。

(参考)
自分のアカウントの確認がしたい人向けに、具体的な確認手順を書いておきます。

0. 「パスワードを忘れた場合はこちら」をクリックし、メールアドレスや名前などを入力して自分のアカウントを特定する。

1. 「パスワードを再設定」の画面で、「上記アドレスが利用できない場合」をクリックする。
1-1. 「メールにアクセスしてください」の画面が表示される。 → パターン1
1-2. 「ご連絡」の画面が表示される。 → 2へ

2. 「ご連絡」の画面でメールアドレスを入力し、「続行」をクリックする。
2-1. 「友達を通じてアカウントを再開」の画面が表示される。 → パターン5
2-2. 「セキュリティのための質問に回答」の画面が表示される。 → 3へ
2-3. 「信頼できる連絡先に助けを求めましょう」の画面が表示される。 → 4へ

3. 「セキュリティのための質問に回答」の画面の表示を確認する。
3-1. 「回答が思い出せませんか？ アカウントの再開を友達に手伝ってもらう」というメッセージが表示されている。 → パターン6
3-2. 上記のメッセージが表示されていない。 → パターン2

4. 直接次の URLにアクセスする。(現在の URLの trustedの部分を sqに書き換える)
ttps://www.facebook.com/recover/sq?cp=xxx@xxx.xxx (cpの値は 2で入力したメールアドレス)
4-1. 「アカウントにセキュリティのための質問が設定されていません。」というメッセージが表示されている。 →  5へ
4-2. 上記メッセージは表示されないが、「回答が思い出せませんか？ アカウントの再開を友達に手伝ってもらう」というメッセージが表示されている。→ パターン8
4-3. いずれのメッセージも表示されていない。 → パターン4

5. 「セキュリティのための質問に回答」の画面の表示を確認する。
5-1. 「回答が思い出せませんか？ アカウントの再開を友達に手伝ってもらう」というメッセージが表示されている。 → パターン7
5-2. 上記のメッセージが表示されていない。 → パターン3

*1:たとえば最近登録したようなアカウントばかりを調べれば、パターン1と3がほとんどになるはずです。

まだまだ続く不正ログイン事件

4月に「複数の会員サイトへの不正ログイン事件が発生」という記事を書いたのだが、その後も多くのサイトで不正ログイン事件が起きている。前回紹介したものも含め、3月から7月にかけて発生した事例についてまとめておく。

まとめ

対象	期間	試行回数	不正ログイン件数 (*1)	成功率 (*2)	影響範囲
WebMoney	8/28 - 8/29	-	1,261	-	顧客情報の閲覧
ポイントタウン	8/20 - 8/22	-	6,765	-	顧客情報の閲覧はなし
ヤプログ！	8/20, 8/24, 8/27	-	5,755	-	顧客情報の閲覧
@games	8/3 - 8/13	-	83,961	-	顧客情報の閲覧
Ameba	4/6 - 8/3	-	243,266	-	顧客情報の閲覧
GREE	7/25 - 8/5	-	39,590	-	顧客情報の閲覧
Tサイト	7/25 - 7/26	-	27	-	ポイント不正利用を確認
ニフティ	7/14 - 7/16	-	21,184	-	顧客情報の閲覧
楽天	5/10 - 7/10	-	-	-	ポイントの不正利用を確認
KONAMI	6/13 - 7/7	3,945,927	35,252	0.89%	顧客情報の閲覧
任天堂	6/9 - 7/4	15,457,485	23,926	0.15%	顧客情報の閲覧
ニッセン	6/18	11,031	126	1.14%	顧客情報の閲覧(?)
じゃらんnet	2/14 - 2/16, 6/3 - 6/15	-	27,620	-	顧客情報の閲覧
ハピネット	4/24 - 5/31	-	9,609 (最大16,808)	-	顧客情報(カード含む)の閲覧
阪急阪神百貨店	- 5/13	-	2,382	-	顧客情報(カード含む)の閲覧
三越伊勢丹	5/6 - 5/23	5,202,002	8,289	0.16%	顧客情報の閲覧
資生堂	5/6 - 5/12	約240,000	682	0.28%	顧客情報の閲覧(?)
ディノス	5/4 - 5/8	約1,110,000	約15,000	1.35%	顧客情報の閲覧
mopita	4/18 - 4/19	-	5,450	-	顧客情報の閲覧
NTT東日本	4/9 - 4/10 (*3)	約24,000	77	0.32%	顧客情報の閲覧
eBookJapan	4/2 - 4/5	2,821	779	27.61% (*4)	顧客情報(カード含む)の閲覧
goo	4/1 - 4/9	-	108,716	-	顧客情報の閲覧はなし
JR東日本	3/31	約26,000	97	0.37%	顧客情報の閲覧(?)
Tサイト	3/26	-	299	-	ポイントの不正利用を確認

(*1) 各事例において、不正ログイン件数に重複が含まれるのか、重複を除いた IDの件数なのかは不明。したがって成功率の意味合いも事例によって異なる可能性がある。
(*2) 成功率は試行回数全体に占める不正ログインに成功した件数の割合を示す。(成功率 = 不正ログイン件数 / 試行回数)
(*3) この期間の他に 4/4に 30件の不正ログインが確認されている。
(*4) eBookJapanへの攻撃の成功率が非常に高いのは、存在しない IDへのアクセス数が試行回数の中に含まれていないためだと思われる。

疑問

これらの事例を見ていて感じるギモンを挙げておく。

• 他社サービスから流出した情報を利用したパスワードリスト攻撃を受けたと主張しているサイトもあるが、総当たり攻撃(ブルートフォース)や辞書攻撃ではなくパスワードリスト攻撃だとする根拠はなにか? (eBookJapanは根拠となる具体的なデータを提示している。)*1
• 攻撃者の動機がよくわからない。ポイント不正利用は金銭に直接結びつくのでわかりやすいが、その他は何を目的としたものなのか? 特にログインに成功しただけで顧客情報も閲覧していないものは?
• 同時期に同業種のサイトが攻撃を受けていると思われる事例があるが、これらは同じ攻撃者によるものなのか? 他の事例ではどうなのか?
• 日本の事例ばかりを取り上げたが、海外でもこの種の攻撃は起きているのか?
• ユーザによるパスワードの使い回しは実際どの程度行われているのか?

パスワードの使い回し

最後のギモンについてはいくつか参考になりそうなデータを挙げておく。

• eBookJapanのケースでは 1回のアクセス試行しかしていない IDが (成功と失敗をあわせて) 1,713で、このうちログインに成功した IDが 386。1回のみ試行しているパスワードが他社から漏洩したものと仮定すると、22.53%のユーザがパスワードを使い回していることになる。
• 海外の複数のパスワード情報漏洩事件において、これらのサイトに共通するアカウントのパスワードを分析したところ、60%以上のユーザが使い回しをしていたとの報告もある。(例1、例2)
• 2007年に Microsoftの研究者が約54万人を対象に行った調査では、平均的なユーザはおよそ25サイトにアカウントを持っていて、約6.5個のパスワードを利用している。つまり 1つのパスワードを 4つのサイトで使い回している。("A Large-Scale Study of Web Password Habits")
• 2012年に IPAが行ったアンケート調査 (5,000名が回答) では、「サービス毎に異なるパスワードを設定している」と回答したのは全体の 22.2%だった。(「2012年度 情報セキュリティの脅威に対する意識調査」報告書について)
• 2012年に トレンドマイクロが行ったアンケート調査 (316名が回答) では、約7割のユーザが3種類以下のパスワードを複数のWebサイトで使いまわしていると回答した。1つのパスワードを使い回しているユーザも 13.9%いた。(プレスリリース- 2012/12/14)

海外の事例

具体的な事例ではないが、Akamaiが先月リリースした最新の 'State of The Internet' レポートの中に、不正ログイン事件に関して触れている部分がある。以下に該当箇所から一部引用する。

The State of the Internet

In the first and second quarters of 2013, Akamai observed attempted account takeover behavior for a number of merchants resulting from reuse of credentials obtained from other sites. Lists of username and password combinations are available in carder forums or on pastebin, or acquired from compromised merchants. Because users often use the same username and password across multiple merchants and other non-commerce sites, this allows attackers to use the compromised credentials on a number of target merchants.

Attackers have been using automated tools — known as “account checkers” — to quickly determine valid user ID/password combinations across a large number of e-commerce sites. Using these tools, attackers can identify valid accounts rapidly and gain access to the accounts, acquiring names, addresses and credit card data from user profiles, and can also fraudulently acquire merchandise.

参照

WebMoney
「WebMoneyファンクラブ」サイトへの不正ログイン発生に関するお知らせ (2013/08/29)

ポイントタウン (GMOメディア)
「ポイントタウン」への不正ログインの可能性について (2013/08/21) (8/23に更新)

ヤプログ！ (GMOメディア)
「ヤプログ！」への不正ログインの可能性について (2013/08/21) (8/24,27に更新)

@games (GCREST)
【重要】アットゲームズ（セルフィタウン）への不正ログインに関するご報告 (2013/08/14)
【不正ログインについて】追加ご報告（8/16） (2013/08/16)

Ameba (サイバーエージェント)
「Ameba」への不正ログインに関するご報告 (2013/08/12)
「Ameba」への不正ログインに関する追加ご報告 (2013/08/16)

GREE
「GREE」への不正ログインに関するご報告 (2013/08/08)

Tサイト (CCC)
Tサイトへの不正ログインによるなりすまし被害について (2013/04/05)
Tポイント不正利用についてのお知らせとお願い (2013/07/26)

ニフティ
不正なログインの発生について (2013/07/17)

楽天
他社サイトから流出したID・パスワードを使った不正ログインの発生およびパスワード変更のお願いについて (2013/07/10)

KONAMI (コナミデジタルエンタテインメント)
「KONAMI IDポータルサイト」への不正ログイン発生のご報告とパスワード変更のお願い (2013/07/09)

任天堂
「クラブニンテンドー」サイトへの不正ログイン発生のご報告とパスワード変更のお願い (2013/07/05) (7/9に更新)

ニッセン
【重要】ニッセンオンラインショッピングサイトへの不正ログイン状況、及びお客様へのお願いについて (2013/06/19)

じゃらんnet (リクルートライフスタイル)
じゃらんnetへの「なりすましログイン」検知のご報告とパスワード変更のお願い (2013/08/08

ハピネット
オンラインショップへの不正アクセスについて (2013/06/03)
オンラインショップへの不正アクセスについて（経過報告）(2013/06/07)

阪急阪神百貨店 (エイチ・ツー・オー・リテイリング)
阪急・阪神百貨店オンラインショッピング、不正アクセスについて (2013/05/29)

三越伊勢丹
三越オンラインショップ・不正アクセスについて (2013/05/25)

資生堂
ワタシプラスにおける不正ログイン被害について (2013/05/17)

ディノス
【重要】セキュリティ強化のためのパスワード変更のお願い (2013/05/08)
【重要】弊社運営のオンラインショッピングサイトへの不正ログイン被害について ※セキュリティ強化のためのパスワード変更のお願い(第二報) (2013/05/09)
【重要】弊社運営のオンラインショッピングサイトへの不正ログイン被害について ※お客様情報を守るための【パスワード確認】のお願い（第三報）(2013/05/13)
【重要】弊社運営のオンラインショッピングサイトへの不正ログイン被害について ※お客様情報を守るための【パスワード確認】のお願い（第四報）(2013/05/16)

mopita (エムティーアイ)
弊社サービスへの不正ログイン被害のご報告 (2013/04/22)

NTT東日本
フレッツ光メンバーズクラブ会員サイトへの不正アクセスについて (2013/04/04)
不正アクセスへの対応等について (2013/04/10)

eBookJapan
重要なお知らせ】不正ログインに関する最終報告 (2013/04/05) (4/6, 4/9, 7/23に更新)

goo (NTTレゾナント)
gooIDアカウント不正ログイン被害について (2013/04/03)
gooIDアカウント不正ログイン被害について（続報）(2013/04/04)
gooIDへの不正ログイン被害について（終報）(2013/04/09)

JR東日本
My JR-EAST での不正ログイン発生とご利用のパスワード変更のお願い (2013/04/17)

更新履歴
(2013-08-07) 海外事例について Akamaiのレポートの内容を追記。
(2013-08-08) GREE、じゃらんnetの事例を追加。
(2013-08-12) Amebaの事例を追加。
(2013-08-19) @gamesの事例を追加。IPAとトレンドマイクロのアンケート調査結果について追記。
(2013-08-20) 不正ログイン件数などを一部補足、修正。
(2013-08-22) GMOメディアの 2件の事例を追加。
(2013-08-30) WebMoneyの事例を追加。

*1:1%前後の成功率であることから、辞書攻撃やパスワードリスト攻撃、あるいはリバースブルートフォース攻撃などの可能性が高いと考えられる。

Operation Ababil Phase 4 開始

このブログでも度々紹介している米金融機関への DDoS攻撃作戦 "Operation Ababil"。3月初めから Phase 3が開始され、5月上旬から一時中断していましたが、先週から Phase 4として再開してしまいました。

Phase 4, Operation Ababil - Pastebin.com

Well, misters! The break's over and it's now time to pay off.

After a chance given to banks to rest awhile, now the Cyber Fighters of Izz ad-Din al-Qassam will once again take hold of their destiny.

As we have said earlier, the Operation Ababil is performed because of widespread and organized offends to Islamic spirituals and holy issues, especially the great prophet of Islam(PBUH) and if the offended film is eliminated from the Internet, the related attacks also will be stopped.

while the films exist, no one should expect this operation be fully stopped.

planing the new phase will be a bit different and you'll feel this in the coming days.

"Mrt. Izz ad-Din al-Qassam Cyber Fighters"

以前からの主張を繰り返しており、攻撃のきっかけとなった反イスラム映画の YouTubeビデオが削除されればすぐに攻撃を停止するとのこと。これまでの攻撃では数十Gpsクラスの大規模な DDoS攻撃を実施しており、米国の金融機関は今回も警戒していると思います。すでに複数の金融機関が被害にあったとのニュースもでています。引き続き今後の状況を注視したいと思います。

Facebookの「セキュリティのための質問」を再設定する方法

前回の記事に書いたように、Facebookではパスワードをリセットするための一つの方法として「セキュリティのための質問」を利用することができる。ただし問題がひとつある。Facebookでは一度設定した「セキュリティのための質問」をあとから変更することができない。他人が容易に推測できるような回答をうっかり設定しまう場合を考えると、これは非常に危険である。3人の架空のアカウントで友達になって…などとわざわざ面倒な方法を使わなくても、簡単にアカウントが乗っ取れてしまう。

そこでどうしても過去に設定した「セキュリティのための質問」を変更したい人のために、ややトリッキーではあるが変更することが可能な方法を紹介する。(ただし正規の手順というわけではないので、実行する場合は自己責任で*1。)

なお現在は「セキュリティのための質問」に代わる機能として「信頼できる連絡先」の機能が提供されている。「信頼できる連絡先」を設定すると「セキュリティのための質問」は無効になるので、こちらを使うことをオススメしておく。(「セキュリティのための質問」はアカウント設定に項目が表示されない。現在の設定状況を確認したい時はこのURLで確認できる。)

(2013-08-13 追記)
追加で検証したところ、上記の『「信頼できる連絡先」を設定すると「セキュリティのための質問」は無効になる』は間違いだということがわかった。「信頼できる連絡先」と「セキュリティのための質問」とを両方設定したアカウントでパスワードリセットを試みると、画面遷移上は「信頼できる連絡先」しか利用できないように見える。しかし直接「セキュリティのための質問」を利用するための URLにアクセスすると、「セキュリティのための質問」を利用してリセットすることが可能。
(別記事も参照のこと。)

概要

この方法の鍵となるのは、設定済みの「セキュリティのための質問」が悪用されてしまいもはや安全ではない、と Facebookに認識させることにある。手順の(1)で「セキュリティのための質問」に正しく回答する必要があるため、自分で設定した回答を忘れてしまった場合にはこの方法は使えない。また手順(2)では現在のパスワードでログインし直す必要がある。

前提条件
・対象となるFacebookアカウントにログインできること (現在のパスワードを知っていること)
・設定済みの「セキュリティのための質問」の回答を知っていること

手順
(1) パスワードリセット機能を利用してパスワードを再設定する。
(2) 古いパスワードでログインする。
(3) アカウント再開の手続きを行う。

以下、順に詳しくみていく。

1. パスワードをリセットする

まずはパスワードリセット機能を使ってパスワードを再設定する。このとき「セキュリティのための質問」に回答する。*2

1-1. 「パスワードを忘れた場合はこちら」をクリックする。
1-2. メールアドレスや名前などを入力して対象のアカウントを特定する。
1-3. 「上記メールアドレスが利用できない場合」をクリックする。
1-4. 新しいメールアドレスを入力する。
1-5. 「セキュリティのための質問」に対する回答を入力する
1-6. 新しいパスワードを入力する。

このあと (1-4) で入力したメールアドレスにリンクが送られてくるが、何もしなくてよい。また (1-6) で設定したパスワードは以降の手順では使用しない。

ちなみに (1-4) のメールアドレス入力画面が表示されず (1-5) の画面に遷移しない場合や、直接 (1-5) の URLを指定してもエラーが表示される場合、そのアカウントでは「セキュリティのための質問」が設定されていないか、無効になっている*3。

2. 古いパスワードでログインする

パスワードリセットを実行したあと、古いパスワードでログインする。アプリやブラウザなどログイン済みのセッションが存在する場合には強制的にログアウトされるので、再度ログインを行う*4。
ここは重要なポイントなので間違えないように。さきほど新しく設定したパスワードではなく、そんなものは知らないよーと何食わぬ顔をして古いパスワードを使うこと。

2-1. 古いパスワードでログインする。
2-2. 「誰かがあなたのアカウントにアクセスしようとしました」というメッセージが表示される。
→ 「私ではありません」をクリックする。
2-3. 「誰かがアカウントにアクセスしようとしましたか？」 というメッセージが表示される。
→ 「アカウントの安全を確保」をクリックする。

(2-1)の時点ではパスワードリセットが実行されたあとで、アカウントはロック状態になっている。しかし古いパスワードでログインし、パスードリセットは自分が実施したものではないと申告することにより、正規のユーザではない第三者が不正にパスワードリセットをかけたことにできる。この場合、古いパスワードでログインしてきたのが正規ユーザと判断され、アカウントを再開するための手続きが開始される。

3. アカウント再開の手続きを行う

ここでは新しいパスワードの設定、登録されているメールアドレスの確認、このアカウントで最近行われた設定変更の確認などが行われる。その中で今回の目的である「セキュリティのための質問」も再設定することができる*5。(ただし設定を無効にすることはできない。)

3-1. 「セキュリティのための質問」に回答し、本人確認を行う。
3-2. 新しいパスワードを設定する。
3-3. メールアドレスを確認する。
3-4. 最近行われた変更内容を確認する。
3-5. 「セキュリティのための質問」を再設定する。
3-6. 「ログイン」をクリックすると、アカウントのロックが解除される。

以上で再設定は完了。おそらくこの方法で再設定したい人はほとんどいないし、誰得な情報ではあるが、せっかく調べたので一応記事にしておく。

*1:再設定によって、「セキュリティのための質問」を使ったパスワードリセット機能が無効になる可能性がある。まあ悪用はされなくなるので目的は達成していると言える。

*2:パスワードリセットは普段ログインしている環境とは異なる環境から実施したほうがよい。例えば Tor Browserを使用するなど。

*3:「セキュリティのための質問」を設定した直後も無効になっており、数日経過しないと有効にならない。

*4:強制的にログアウトされるかどうかはパスワードリセット時の設定による。

*5:画面キャプチャするのを忘れたので細かい手順は省略。またアカウント再開がこのとおりにスムーズにいかない可能性もある。→ 手順を再度確認できたので追記した。

Facebookのパスワードリセット機能のまとめ

Facebookのパスワードを忘れてしまった場合、「パスワードを忘れた場合はこちら」のリンクから、パスワードを再設定することができる。いわゆるパスワードリセット機能で、大抵の Webサービスには似たような機能があると思うが、Facebookでは実に多様な方法でパスワードをリセットすることができる。そしてこれがセキュリティ上問題になったり、混乱を生む原因にもなっているのではないかと思う。ということで Facebookのパスワードリセット機能についてまとめておく。(続編も一緒にどうぞ！)

通常の方法

まず、もっともポピュラーな方法として以下がある*1。

1-1. Googleアカウントでログインする

1-2. 登録しているメールアドレスにメールで確認コードを送る

1-3. 登録している携帯電話に SMSで確認コードを送る

1-4. コードジェネレータを利用する

Facebookに Gmailのメールアドレスを登録している場合、Googleアカウントでログインするのが最も簡単な方法だ (1-1)。Facebookに登録された Googleのアカウントでログインし、Facebookにメールアドレスの表示を許可するだけで OK。すぐに新しいパスワードを再設定することができる。(Google以外にもアカウント連携できるものがあるかも。未確認。)

Gmail以外のメールアドレスを登録している場合や携帯電話番号を登録している場合には、(1-2) か (1-3) の方法で 6桁の確認コードを受信できる。またログイン承認 (いわゆる 2段階認証) の機能に用いられるコードジェネレータを有効に設定している場合には、それを使ってもよい (1-4)。いずれの場合でも確認コードを正しく入力できればパスワードの再設定が可能だ。

ややイレギュラーな方法

次に上記のいずれの手段も利用できない場合に使う方法を紹介する。スマホを紛失したり、メールアドレスにもアクセスできないというかなり特殊な状況だとは思うが、こういう緊急時(?)でもパスワードをリセットすることができる。

2. セキュリティのための質問に回答する

「セキュリティのための質問」は他のサービスでは「秘密の質問」などと呼ばれることもある。本人以外には知りえない情報をあらかじめ登録しておき、その内容を答えさせることで本人かどうかを確認するものだ。しかし実際には、質問の選択肢が限定されていて、質問の内容も本人以外が容易に知りうるものが多く、アカウント乗っ取りに利用されるケースもある。なかなか問題の多い機能である。

Facebookでは以下の 6つの中から質問を選択して、あらかじめ回答を登録しておく。

• 小学校1年生の時の担任の先生の苗字は？
• お母さんが生まれた町の名前は？
• 8才の時に住んでいた町の名前は？
• 小学校3年のときの担任の先生の名前は？
• おじいさんの職業は？
• おばあさんの職業は？

選択肢が少ないうえに、本人以外には知りえない秘密かと言われれば疑問を感じるものもある。

ところで秘密の質問を使ってパスワードリセットを行うのは他のサービスでは一般的に行われているが Facebookではやや日陰の存在だ。なぜかというと、実は Facebookでは設定することをもはや推奨していないからだ(後述する「信頼できる連絡先」の利用をすすめている)。機能としては存在しているのに、設定項目としてどこにも表示されないのである。以前は「アカウント設定 > セキュリティ」の中に項目として表示され、一度設定を行うと以後表示されなくなっていた。しかし現在は設定の有無に関係なく表示されないようになっている*2。

また「セキュリティのための質問」は一度設定すると以後その内容を変更することができなくなる。その理由はヘルプによると、次のとおりである。

セキュリティのための質問を変更することはできますか。

ユーザーのアカウントと情報を安全な状態に維持するため、アカウントのセキュリティのための質問を一度設定すると、変更することはできません。ご不便をおかけして申し訳ありません。

うっかり間違って他人が容易に推測可能な回答を設定してしまった場合はどうすればいいのだろうか。設定してもあとから変更できるようにするべきだと思うがこういう仕様なので仕方がない。(実はちょっとした技を使うと再設定することはできるのだが、それについては別記事で。)
ちなみに Yahoo! Japanでも Facebookと同じように、一度設定すると変更できない仕様になっている。

というわけなので、Facebookの「セキュリティのための質問」は強制ではないし、設定項目にも表示されないし、一度設定したら変更できないし、うっかり簡単な答えを設定したら悪用される危険性が高いので、設定しないほうがいいと思う。万が一の場合に備えて設定しおきたいという奇特な人は、ランダムな回答を登録してパスワード管理ソフトにでも覚えさせておけばいい。

なお設定項目に表示されないため、自分が過去に設定したかどうか忘れてしまうこともあるだろう。そういう場合には以下の URLにアクセスすると、セキュリティのための質問を設定したか確認することができる。

https://www.facebook.com/update_security_info.php (要ログイン)

3. 友達の助けを借りる

さて次に SNSらしいユニークな方法が「友達の助けを借りる」というものだ。これは実際には次の 2つのパターンにわかれる。

3-1. 信頼できる連絡先を事前に登録している場合

「信頼できる連絡先」とは何かというと、パスワードリセットを行う際に助けてもらう友人をあらかじめ登録しておく機能のことだ。3〜5人の友達をあらかじめ登録しておくことができる。この場合のパスワードリセットの手順は以下のようになる。

1. あらかじめ登録した友達 3-5人の中から 3人の友達に連絡する。
2. 友達にこの URL にアクセスしてコードを取得してもらい、そのコードを聞く。
3. 3人から聞いた 3つのコードを入力する。

3つのコードがすべて正しく入力できれば、パスワードを再設定することができるようになる。
これは「セキュリティのための質問」に代わるものとして今年 5月に導入された比較的新しい機能なので、まだ利用できないユーザがいるかもしれない*3。

3-2. 信頼できる連絡先を登録していない場合

信頼できる連絡先を登録していない場合はどうなるかというと、実はパスワードリセットを行う際にあとから助けてもらう友人を選択することもできる。この場合の手順は以下のとおり。

1. 友達一覧の中から 3人の友達を選択する。
2. 3人の友達に手順を説明するメッセージが送信される。
3. 3人の友達から確認コードを取得し、3つのコードを入力する。

基本的な手順はさきほどとほとんど変わらないが、助けを借りる友達をあらかじめ登録しておくか、あとから選択するかという点が異なる。そしてこの違いが実は問題で、いわゆる「3人の架空アカウントと友達になると乗っ取られる」問題はこの機能を悪用するものだ。フェイスブックナビが注意喚起をしたことで最近ちょっと話題にもなったが、実はこの問題自体は約 2年前から存在している。そしてこれを解決するために改良されたのが前述の「信頼できる連絡先」の機能である。

攻撃者はあらかじめ架空のダミーアカウントを複数登録し、ターゲットとなるアカウントに友達申請をする。運良く 3人の友達(いずれもダミー)が承認されれば、(3-2)の手順を利用して攻撃者はターゲットのアカウントのパスワードをリセットできるという仕組みだ。しかしこの乗っ取り方法は攻撃者からすれば面倒で効率が悪いし、2年も前から存在するのにこの方法で乗っ取られたという話は聞いたことがない。
また最近新しく登録したアカウントではそもそもこの方法は有効になっていないほか、古いユーザのアカウントでも無効になっている場合がある。おそらくセキュリティの設定項目などが影響しているのだと思うが、無効になるアカウントの条件がはっきりしないため、この攻撃方法が有効なアカウントの総数もよくわかっていない*4。まああまり心配する必要はないと思うが、心配な人は「信頼できる連絡先」を登録しておけばよい*5。

まとめ

• Facebookのパスワードリセットの方法はいろいろある。
• (2)と (3-2)の方法は攻撃者に悪用されるかもしれないので要注意。
• 通常の方法が使えない緊急時に備えるのであれば、「セキュリティのための質問」は設定しないで、「信頼できる連絡先」を設定しよう。
• アカウントによってどの方法が使えるかはそれぞれ異なる(設定項目の有無や、登録時期など様々な要素が影響すると思われる)。
• 自分のアカウントではどの方法が使えるのか、一度確認しておくべき。Facebookは告知もなしに頻繁に仕様を変更するので、定期的に確認するのもいいかもしれない。

1. 通常の方法
 1-1. Googleアカウントでログインする
 1-2. 登録しているメールアドレスにメールで確認コードを送る
 1-3. 登録している携帯電話に SMSで確認コードを送る
 1-4. コードジェネレータを利用する
2. セキュリティのための質問に回答する
3. 友達の助けを借りる
 3-1. 信頼できる連絡先を事前に登録している場合
 3-2. 信頼できる連絡先を登録していない場合

*1:この他にもあるかもしれないが未確認。

*2:いつからこのような変更が行われたのか、よくわからない。信頼できる連絡先の機能が提供されたあとからか?

*3:Facebookでは新機能が全ユーザに行き渡るまでに数週間かかることが多い。

*4:おそらく近いうちにこの機能は全ユーザで無効になると思われる。

*5:ただし「信頼できる連絡先」を設定しているにもかかわらず、(3-2)の手順が実行できるアカウントが存在する。どういう条件でそうなるのかわからない。

NSAの監視プログラムに関する米政府の主張

Edward Snowden氏のリークによって大騒動となっている NSAの監視プログラムについて、今週、米国議会の上院や下院において米政府からの情報開示や、NSA長官などの政府高官による証言が相次いで行われました。これらの情報から、現時点でのこの問題に関する米政府側の主張をちょっと整理してみます。

−−−−
上院情報委員会に提出された文書や、PBSのインタビューでのオバマ大統領の説明によると、NSAの監視プログラムは大まかに次の2つがある。これらはその根拠となっている法律の条項から 215 programや 702 programなどと呼ばれている。

• Section 215 of the USA PATRIOT Act にもとづくデータ収集 (215 program)
• Section 702 of the FISA Amendments Act にもとづくデータ収集 (702 program)

これらのプログラムはいずれも

• 法律によって規定された範囲内である (USA PATRIOT Act of 2001, FISA Amendments Act of 2008)
• 議会によって許可されている (authorized)
• 裁判所 (FISC: Foreign Intelligence Surveillance Court) によって承認されている (approved)
• 司法省 (DOJ)と国家情報長官室 (ODNI)によって定期的にレビューされている

(だから問題ないと米政府は主張している。)

215 program はバルクで電話会社からメタデータ(電話番号ペアや通話時間などの通話記録のこと。通話内容は含まない)を収集しているが、このデータを検索するには対象者が海外のテロリスト組織の活動に関係するという相応の根拠が必要。根拠のないデータ検索は違法となる。実際に2012年の1年間にNSAによって調査が行われたのは300件未満。また記録されたデータは5年以内に破棄される。なお下院情報特別委員会の公聴会でのNSA長官の証言によると、NSA内でこの通話記録データベースにアクセスできる権限をもつのは20人のアナリストと2人の管理者の合計22人のみである。

702 program はバルクではなく、特定のターゲットに関するメールなどのコンテンツデータを都度収集するもの。テクノロジー会社に対して個別にデータ開示の要求を行う。米国外の非米国民の通信だけを対象としたもので、意図せずに収集された米国民のデータは適切に保護される。

215 programと 702 programの2つの監視プログラムによる成果として、2011年9月11日の同時多発テロ事件以降、これまでに20ヶ国で50件以上、米国内だけに限定すれば10件以上のテロ実施計画を未然に防ぐことができたとしている。この中にはニューヨーク市の地下鉄爆破計画、ニューヨーク証券取引所爆破計画などが含まれている。

−−−−
(補足事項)
今回の騒動は、Verizon Business Network Servicesに対して 3ヶ月分(2013年4月25日から7月19日まで)の通話記録をNSAに提出するように求める FISCの命令書 ("Top Secret")が The Guardian紙によってスクープされたことからはじまった。またその後、実は 2006年から 3ヶ月毎にこの裁判所命令が更新され続けていることや、AT&Tなど他の大手電話会社に対しても同様に行われていることなども報道された。(215 program)

続いてリークされた PRISM(US-984XN)に関する "Top Secret"資料によると、このプログラム(702 program) に参加しているのは Microsoft, Yahoo, Google, Facebook, PalTalk, AOL, Skype, YouTube, Appleの 9社*1。このうち Facebook, Microsoft, Apple, Yahoo! の 4社は政府機関へのデータ開示の件数を公表したが、情報開示にあたって政府から求められた条件によって、一般の犯罪捜査に関するものもすべて含めたおおよその件数のみが公開された。そのためこのうち何件が PRISMに関連するものなのかはわからない。一方、Googleは PRISM関連のものだけを個別に開示する許可を求めて FISCに別途申し立てを行っている。

PBSのインタビューにおいて「FISCは NSAからのリクエストを承認せず拒否したことがあるのか?」との質問に対して、オバマ大統領は直接質問に答えなかった*2。FISCの承認という司法によるチェック機能が実際に有効に働いているとは言い難い*3。

テロを未然に防止したという成果についても、いくつかのケースではこれらの監視プログラムが決定的な役割を果たした場面もあるだろうが、すべてのケースではないだろう。プライバシーを脅かすような包括的な監視プログラムに頼らなくても、テロに対応できる方法は他にあるのではないだろうか? という当然の疑問が湧く*4。また監視プログラムの対象範囲についてもまだ曖昧ではっきりしない部分が多く、上記 2つのプログラム以外にも監視プログラムが存在する可能性はある。NSAは4つの監視プログラム(MAINWAY, MARINA, NUCLEON, PRISM) を運用しているとの報道もあり、それによると電話とインターネットの通信について、それぞれメタデータとコンテンツデータを取得しているとある。下院の公聴会では、NSAが 215 programで収集しているのは電話の通話記録だけだと NSA長官は証言しているが、一方で他の法執行機関は Section 215によってそれ以外の情報の収集も許可されていると司法副長官が証言している。

今後 Snowden氏からさらに機密資料がリークされたら、より詳しい内容がわかるかもしれない*5。

(Snowden氏は香港での最初のインタビューの際に亡命を希望する国としてアイスランドの名前を挙げていたが、Snowden氏がアイスランド政府に対して亡命を希望すると非公式に打診していることが 6/18日にわかった。)

*1:プログラムに参加した順に記載。Skypeは Microsoftが、YouTubeは Googleがそれぞれ買収しているので実際には 7社。

*2:オバマ大統領は「リクエスト件数は驚くほど数が少ないんだ。」と質問をはぐらかした。

*3:Snowden氏は FISCを "rubber stamp"だと形容している。一方、NSA長官は「"rubber stamp"だとは思わない。FISCの連邦判事は素晴らしい仕事をしている。」と反論している。

*4:下院情報特別委員会の公聴会で FBI副長官は具体的に4つのケースを明らかにしたが、すでにこれらのケースにおいて監視プログラムの果たした役割について疑問が提示されている。

*5:NSAによる監視プログラムの全体像を把握することは難しいが、AP通信のこの記事が非常に参考になり必見。http://bigstory.ap.org/article/secret-prism-success-even-bigger-data-seizure