LulzSecリーダー Sabuへの判決

5月27日、LulzSecのリーダーだった Sabuについに判決がでました。情報提供者として協力してきた結果が非常に評価されて、保護観察つきながら自由の身となりました (“time served and one year of supervised release”)。米司法省のプレスリリースによると Sabuの協力によって、8人の逮捕につながり、300以上のサイバー攻撃を未然に防いだり被害を軽減することができたとされています。

Leading Member Of The International Cybercriminal Group “Lulzsec” Sentenced In Manhattan Federal Court

Among other things, at law enforcement direction, Monsegur engaged in proactive cooperation that enabled the Government to identify, locate, and arrest eight of his co-conspirators, including Hammond. In addition, as a direct result of Monsegur’s cooperation, the Government was able to prevent or mitigate over 300 cyberattacks that were being planned or carried out by others, including on the computer servers of U.S. and foreign governments, international intergovernmental organizations, and private corporations. Monsegur also provided information on vulnerabilities in certain critical infrastructure, including at a U.S. water utility, that enabled law enforcement to secure that infrastructure.

LulzSecは 6人のコアメンバーから構成されており、約1年前にイギリスで他のメンバー 3人への判決が出ています。リーダーの Sabuはメンバーの中で誰よりも早く逮捕されていながら、他のメンバーに対する捜査に協力するなどしていたため、これまで判決が度々延期されていました。これで消息不明の Avunitを除く 5人のメンバーに判決が出たことになります。

LulzSec関連の主なタイムライン

2011年5月

LulzSecが活動開始 (最初のツイート)

2011年6月

FBIにより Sabuが逮捕される → 情報提供者として捜査に協力することに

2011年6月

LulzSecが活動停止を発表 (発表ツイート )

2011年7月

イギリスで Tflowが逮捕される

2011年7月

イギリスで Topiaryが逮捕される

2011年8月

Sabuが裁判で有罪を認める (非公開)

2011年9月

イギリスで Kaylaが逮捕される

2011年9月

アイルランドで Pwnsauceが逮捕される

2012年3月

Sabuがすでに 2011年に逮捕され FBIに協力していたことが明らかになる

2013年5月

イギリスで Topiary, Kayla, Tflowの 3人に有罪判決

2013年10月

アイルランドで Pwnsauceに有罪判決

2014年5月

アメリカで Sabuに有罪判決 ← イマココ

LulzSecメンバーへの判決内容

名前	国	判決時期	説明
Sabu	アメリカ	2014年5月	LulzSecのリーダー。実はFBIに最初に逮捕されていたが、その後FBIへの協力者として密かに活動し、他のメンバー逮捕の決め手となる情報を提供した。裁判ではこうした貢献が考慮され、判決前の未決勾留期間(約7ヶ月)で刑を相殺し、1年間の保護観察処分つきながら自由の身となる。
Topiary	イギリス	2013年5月	LulzSecの広報役として Twitterアカウントの運用やプレスリリース文の作成などをしていた。禁固24ヶ月の実刑判決を受ける。ただしまだ20才なので “Young Offender Institiution” (少年刑務所)。2013年6月に出所。
Kayla	イギリス	2013年5月	ネット上では16才の女性として活動していた。禁固30ヶ月の実刑判決を受ける。2014年3月に出所。
T-flow	イギリス	2013年5月	活動当時16才で実名は伏せられていたが、裁判の過程で明らかになった。禁固20ヶ月 (執行猶予2年)、300時間の奉仕活動の判決を受ける。
Pwnsauce	アイルランド	2013年10月	OWASPの活動にも参加するセキュリティ研究者(学生)だったことが話題となった。2013年7月に起訴されて保護観察を経たあと、2013年10月の判決では 5,000ユーロの罰金刑のみを受ける。
Avunit	??	??	消息不明

あれから 3年たってようやく…

(2014-05-29 追記)
Topiaryの書いた記事と Kaylaへのインタビュー記事がでてました。
Sabu, the FBI and me: how his light sentence affects the hacking landscape | Jake Davis | Comment is free | theguardian.com
Ryan Ackroyd: 'Sabu Took Snitching to a Whole New Level'

(参考情報)
http://www.wired.com/2014/05/hector-monsegur-sabu-sentencing/
http://arstechnica.com/tech-policy/2014/05/scenes-from-the-sabu-sentencing-im-not-the-same-person-you-saw-three-years-ago/
http://www.nytimes.com/2014/05/28/nyregion/hacker-who-helped-disrupt-cyberattacks-is-allowed-to-walk-free.html
http://www.theguardian.com/technology/2014/may/27/hacker-sabu-walks-free-sentenced-time-served
http://www.ibtimes.co.uk/anonymous-hacker-turned-informant-sabu-sentenced-one-years-probation-1450172
http://cryptome.org/2014/05/monsegur-sentencing.htm
http://www.dailydot.com/news/sabu-hector-xavier-monsegur-fbi-antisec-anonymous-sentenced/
http://threatpost.com/lulzsec-hacker-sabu-sentenced-to-time-served/106295
http://www.itmedia.co.jp/enterprise/articles/1405/28/news040.html

JICS2014のセキュリティ・トラックに参加しました

先週 1/14,15に JAPAN IDENTITY & CLOUD SUMMIT (JICS) が開催され、その中のセキュリティ・トラックに参加させてもらいました。@ITさんの記事(の後半)でセキュリティ・トラックの内容について紹介されています。

Japan Identity ＆ Cloud Summit 2014レポート：なぜ僕らはまだパスワードリスト攻撃に悩まされ続けるのか - ＠IT

関連するブログや Togetterのまとめもあります。
JICS2014に参加してきました。 « (n) (パネリストの一人である辻さんの記事)
JICS 2014のセキュリティ・トラックを聞いて思ったこと - r-weblife (OpenIDファウンデーション・ジャパンのエバンジェリスト ritouさんの記事)
#JICS2014 #Sec Track - クレイジーダブルポケットフランネルチェックシャツ - Togetterまとめ

このトラックでは、「ユーザの視点」「攻撃者の視点」「サイト運営者の視点」でそれぞれパスワードに関する問題について話をし、その後にパネルディスカッションを行いました。

ユーザの視点 (私)

情報漏洩の事例をもとに、多くのユーザが弱いパスワードをつけたり、パスワードを使い回したりしている状況の確認と課題の提起

攻撃者の視点 (辻さん)

攻撃者はどうやってパスワードを破るのか、攻撃手法や利用されるツールの紹介

サイト運営者の視点 (徳丸さん)

パスワードリスト攻撃への対策方法の紹介と、サイト側がどこまでやるべきなのか、悪いのは誰なのかを整理

パネルでは上記 3人にヤフーの楠さんも加わって、「リスト型攻撃の対策は結局どうしたらいいのか」「パスワードは本当にオワコンなのか」などをテーマに、どういう方向に進んでいけばいいのか、パネリスト達で議論しました。こういうパネルディスカッションには時々参加させてもらいますが、その中でも今回のパネルは中々充実した内容で非常におもしろかったと思います(参加者がどう思われたかはわかりませんが…)。内容については上の記事をご参照ください。
答えがすぐに出るようなテーマではありませんので、継続して取り組んでいく必要がありますね。

あと私の資料の中で紹介したネタについて、参考情報を以下にのせておきます。

漏洩アカウントのチェックサイト
Have I been pwned? Check if your email has been compromised in a data breach
セキュリティ研究者の Troy Hunt氏が運営しているサイト。過去に漏洩したアカウント情報をデータベース化して検索できるようにしてあります。自分のメールアドレスを事前に登録しておくと、漏洩した際にメールで知らせてくれる機能や、ドメイン検索する機能(そのドメインの管理者であることを証明する必要あり)もあります。

漏洩したパスワードを公開、販売しているサイト
UNIQPASS v14 · Large password list
Leaked Passwords
UNIQPASSは様々なサイトから漏洩したデータを集約したリストで、約2億4千万件のパスワードが含まれているらしいです。

パスワードが弱いかどうか判定するサイト
How Strong is Your Password?
パスワード チェッカー: 安全性の高いパスワードの使用 | Microsoft セキュリティ
Telepathwords: preventing weak passwords by reading your mind.
いろいろありますが、Microsoft Researchが提供する Telepathwordsはちょっとユニークです。パスワードを1文字ずつタイプすると、その文字から次の文字を推測して表示してくるので、心を読まれたような気分になります。過去に漏洩したパスワードやよく使われる言葉などから、次の文字を推測しているようです。同じパスワードでもサイトによってチェック内容が異なるため判定結果が変わってきます。

パスワードの探索空間を表示するサイト
GRC's | Password Haystacks: How Well Hidden is Your Needle?  
パスワードに使われている文字の種類と長さの情報をもとに、ブルートフォース攻撃を試みる場合の探索空間の広さを教えてくれるサイトです。パスワードの強さを判定してくれるわけではないので注意。

情報セキュリティに対する意識調査
プレス発表 「2013年度 情報セキュリティに対する意識調査」報告書を公開：IPA 独立行政法人 情報処理推進機構
IPAが毎年行っているアンケート調査の2013年度の結果。一般ユーザのパスワードの利用状況についても参考になるデータがのっています。

以上です。

JICS2014の関係者、参加者の皆様、ありがとうございました！！

よく使われるパスワード 2013年版

先週 SpalshData が "Worst Passwords of 2013" のリストを発表しました。SpalshDataはパスワード管理ソフトなどスマートフォン向けの製品を開発している会社ですが、その年に起きた情報漏洩事件のデータをもとに、ユーザがよく使うパスワードのトップ25を調べて、2011年から毎年発表しています。

• 2013年 "Password" unseated by "123456" on SplashData’s annual "Worst Passwords" list
• 2012年 Scary Logins: Worst Passwords of 2012 — and How to Fix Them
• 2011年 When "Most Popular" Isn't A Good Thing: Worst Passwords of the Year – And How to Fix Them

リストの変遷を表にしてみました。

順位	2011年	2012年	2013年
1	password	password	123456
2	123456	123456	password
3	12345678	12345678	12345678
4	qwerty	abc123	qwerty
5	abc123	qwerty	abc123
6	monkey	monkey	123456789
7	1234567	letmein	111111
8	letmein	dragon	1234567
9	trustno1	111111	iloveyou
10	dragon	baseball	adobe123
11	baseball	iloveyou	123123
12	111111	trustno1	admin
13	iloveyou	1234567	1234567890
14	master	sunshine	letmein
15	sunshine	master	photoshop
16	ashley	123123	1234
17	bailey	welcome	monkey
18	passw0rd	shadow	shadow
19	shadow	ashley	sunshine
20	123123	football	12345
21	654321	jesus	password1
22	superman	michael	princess
23	qazwsx	ninja	azerty
24	michael	mustang	trustno1
25	football	password1	000000

トップ5の安定感たるや素晴らしいものがあります。2013年のリストを見ると、あちらこちらに Adobeのケースの影響が見えますね。細かな順位の変動にあまり意味はないと思いますが、ユーザがどのようなパスワードをつけているのかがよくわかります。Adobeの例でみると、漏洩件数のおよそ 1.5%が「123456」で、トップ10だけで全体の 3%を越える結果になっています。これはつまり password や 123456 などのパスワードを使ってリバース攻撃をかけると、そこそこの確率で攻撃が成功するということです。なんだ、パスワードリストなんていらないですね。

よいパスワードをつけること、使い回しをしないことはユーザの責任ではありますが、その結果が現状なわけで、不正ログインを防ぐためにどうすればよいか、みんなの頭を悩ませているわけです。

Adobeでよく使われるパスワード Top 10

Adobeから大規模な情報漏洩が起きたことが先月明らかになったが、漏洩規模は当初想定よりもかなり大きく、およそ1億5千万件のアカウント情報が漏洩している(アクティブなアカウント約3,800万件を含む)。このうち 3DES (ECBモード) で暗号化されたパスワードがおよそ 1億3千万件含まれており、これまでにさまざまな分析が行われている。SCG (Stricture Consulting Group) のセキュリティ研究者は、暗号化パスワードとともに漏洩した平文のパスワードヒントなどを手掛かりとしてパスワードの解読を試みており、Top 100パスワードリストを公開している。最も多く使われていたパスワードは「123456」で約191万件、これは全体の約 1.5%に相当する。

Adobeの情報流出で判明した安易なパスワードの実態、190万人が「123456」使用 - ITmedia エンタープライズ

これらの記事を読んで、日本のユーザでも同じだろうかという疑問が湧いたので、少しだけ調べてみた。jpドメインでは yahoo.co.jpが最も多く約100万件のメールアドレスが登録されていたので、これをサンプルとして調査することにした*1。(ちなみに 2位は hotmail.co.jp、3位は ybb.ne.jpで、jpドメインで約327万件のメールアドレスが登録されていた。)

100万件のうち14万件は暗号化されたパスワード情報を含んでいなかったため、残りの86万件のパスワード(ユニークなパスワード約63万件)を利用者の多い順に並べてみた。
(注：暗号化されたパスワードが復号できているわけではないので、あくまでも推測にすぎない。)

順位	全体での順位	暗号化されたパスワード (Base64)	パスワード(推測)	該当者数	%	パスワードヒントの例
1	1	EQ7fIpT7i/Q=	123456	4652	0.54	654321, 1〜6, number
2	2	j9p+HwtWWT86aMjgZFLzYg==	123456789	1265	0.15	suuji, 987654321
3	5	j9p+HwtWWT/ioxG6CatHBw==	12345678	890	0.10	1-8, 1〜8, 87654321
4	3	L8qbAD3jl3jioxG6CatHBw==	password	819	0.10	pass, simple is best, pasuwa-do, P@ssw0rd
5	8	7LqYzKVeq8I=	111111	720	0.08	1*6, simple number, 222222
6	46	e+4n2zDarnvioxG6CatHBw==	1qaz2wsx	630	0.07	itumono, 123qweasd, 2wsx1qaz
7	-	ZnwI3yrEWS4=	sakura	620	0.07	haru, flower, hana, dog, cat, cherry
8	12	diQ+ie23vAA=	000000	579	0.07	000, 111111, 0ga6, zero6, 06, 6keta
9	41	TduxwnCuA1U=	112233	489	0.06	123, suuji, 332211
10	36	XpDlpOQzTSE=	121212	486	0.06	212121, 1212, kakeashi, kame

この結果から言えそうなことは、

• 英字や英単語は少なく、数字のパスワードが多い
• 日本語のパスワードやパスワードヒントが含まれる
• 脆弱なパスワードの割合は全体の平均よりは少ない

英字が少ない点について補足すると、たとえば全体で4位の「adobe123」は約21万人ものユーザが使っているのに、yahoo.co.jpドメインに限るとわずか80人しかいない。全体 9位の「photoshop」も100人だけだ。また全体では100位圏外の「sakura」が 7位にはいっているのも日本ならではと言えるだろう。(ただし yahoo.co.jpドメインだからといってすべて日本のユーザとは限らないが。)

またこれは全体にも共通する点だが、パスワードヒントにパスワードをそのまま書いている(あるいは逆順にして書いている)人がたくさんいることもわかった。パスワードヒントに何を書けばよいかわからず、結局そのままパスワードを書いてしまうのだろう。「秘密の質問と答え」でも同じだが、パスワードを忘れたユーザのための機能が抜け穴になってしまっているようだ。こうした機能があること自体よくないと言えるだろう*2。

今回紹介したパスワード Top 10はユーザが使ってしまいがちな良くないパスワードの例である。自分のパスワードには決して使わないこと！そしてパスワード漏洩時の影響を最小限に抑えるため、複数のサイトでパスワードの使い回しをしないこと！

(参考記事)
日本語では徳丸氏の記事、英語では Sophosの記事が秀逸でもっとも参考になる。また Troy Hunt氏は過去のパスワード漏洩事件でも優れた分析記事を書いており今回も大変参考になる。

Adobeサイトから漏えいした暗号化パスワードはなぜ解読されたか | 徳丸浩の日記
http://blog.tokumaru.org/2013/11/adobe.html

Anatomy of a password disaster – Adobe’s giant-sized cryptographic blunder | Naked Security
http://nakedsecurity.sophos.com/2013/11/04/anatomy-of-a-password-disaster-adobes-giant-sized-cryptographic-blunder/

Troy Hunt: Adobe credentials and the serious insecurity of password hints
http://www.troyhunt.com/2013/11/adobe-credentials-and-serious.html

pivotal analytics - An analysis of the Adobe password dump
http://pv.tl/blog/2013/11/03/adobe-password-analysis/

1286: Encryptic - explain xkcd
http://www.explainxkcd.com/wiki/index.php?title=1286:_Encryptic

How an epic blunder by Adobe could strengthen hand of password crackers | Ars Technica
http://arstechnica.com/security/2013/11/how-an-epic-blunder-by-adobe-could-strengthen-hand-of-password-crackers/

Just how bad are the top 100 passwords from the Adobe hack? (Hint: think really, really bad) | ZDNet
http://www.zdnet.com/just-how-bad-are-the-top-100-passwords-from-the-adobe-hack-hint-think-really-really-bad-7000022782/

*1:といっても、grepして cutして sortして uniqしただけです。手抜きですいません。

*2:現在 Adobeアカウントではパスワードヒント機能は使われていないようだ。

OTRでオフレコチャット！

前回の記事で (Perfect) Forward Secrecy (FS) のテーマを取り上げたが、これは TLS/SSLだけに限定した話ではない。そこで今回はメールやチャットなどのメッセージングの話題を取り上げたいと思う。

PGP

メールにおける End-to-Endの暗号化としては Pretty Good Privacy (PGP) が以前から広く使われている。NSAの内部情報をリークした Edward Snowden氏もジャーナリストと連絡を取るにあたって、必ずPGPによる暗号化を行うように要求したという。さて、PGPでは各メッセージの暗号化に使われるセッション鍵 (毎回ランダムに生成される) を受信者の公開鍵で暗号化して送る。また各メッセージのハッシュに対して送信者の秘密鍵を用いて署名を行う。一方の受信者は自身の秘密鍵でセッション鍵を復号し、この鍵で暗号化されたメッセージを復号する。また送信者の公開鍵で署名を検証することができる。PGPではこのような仕組みによって、送信されるメッセージの秘匿性と、送信者の認証を実現している。(暗号化と署名の両方とも RSAを使うか、暗号化に ELG + 署名に DSAという組み合わせで使われる。)

ここで PGPによって暗号化されたメールを通信経路上で盗聴できる攻撃者を想定しよう(NSAがまさにこの攻撃者に該当する)。この攻撃者は受信者の秘密鍵を持っていないため、盗聴した暗号メッセージを復号することはできない。しかし将来なんらかの手段によって攻撃者が受信者の秘密鍵を入手(または解読)できた場合、この攻撃者はそれまでに保存したすべての暗号メッセージを復号して見ることができてしまう。

これは前回触れた TLS/SSLにおけるRSA鍵交換と全く同じ問題だと言える。つまりPGPは Forward Secrecyを実現できていない。では FSに対応したメッセージングはないかというと、それが今回紹介する Off-the-Record (OTR) Messagingである。

OTR

Off-the-Record Messaging はその名が示すとおり、メッセージングにおいていわゆる「オフレコ」を実現するための仕組みである。「オフレコ」の会話の場合、会話の内容はその場にいた当事者しかわからない。また録音でもされない限り、その場の発言内容についてあとから誰も証明することができない。当事者達ですらそれは不可能であり、「そんなことは言っていない、言ったという証拠がどこにある」と自らの発言を否定することだってできる。これが「オフレコ」の特徴である。OTRもこれらの特徴を備えている。

OTRが提供する主な機能は以下の4つである。

1. Encryption (暗号化)
2. Authentication (認証)
3. Deniability (否認可能)
4. Perfect Forward Secrecy (前回の記事を参照)

当事者だけにしかわからないようにメッセージを伝えるためには、相手を認証 (2) した上で相手だけが復号できるように暗号化 (1) を行う必要がある。OTRでは DSAの公開鍵でまず通信相手の確認(認証)を行い、次に Diffie-Hellman鍵交換によって暗号化に必要な共通鍵を生成している。また毎回DH鍵交換を行うことによって Forward Secrecy (4) にも対応している。

OTRがちょっと変わっているのは (3)の性質だろう。「オフレコ」を実現するには発言内容をあとから否認することができなくてはならない。そのため OTRでは第三者が検証できるようなメッセージへの署名は行わない。OTRではメッセージ送信の際に MAC (Message Authentication Code) を付加するが、新しいメッセージを送信する際に古いメッセージの MACに使用した鍵を平文で送信してしまう。そのため古いMAC鍵はもはや当事者だけのものではなくなり、それまでにやりとりされた古いメッセージに限って第三者が偽造することも可能になる。これにより当事者達の否認可能性を実現しているのである。

(OTRの簡単な概要については 2005年のカンファレンス資料 (PDF)がわかりやすいのでオススメ。)

PGPとOTRとの比較

	鍵交換 (暗号化)	認証 (署名)	FS (PFS)
PGP	RSA	RSA	×
	ELG	DSA	×
OTR	DHE	DSA (署名なし)	○

OTRの実装

OTRはオープンソースでライブラリとして公開されており、多くのメッセージングソフトが対応している。代表的なソフトウェアとしては、Pidgin (Windos/Mac/Linux), Adium (Mac), IM+ (Android/iOS他) などがある。(Adium, IM+にはOTR機能が組み込まれているが、Pidginではプラグインとして実装されている。)
これらのソフトは Google Talk, AIM, Yahoo!, MSN, Facebook, Twitterなど複数のメッセージサービスに対応しており、これらのサービスの中で OTRを実現することが可能となっている。

OTRの基本的な使い方

使い方は非常に簡単。初回のみ鍵の生成が必要で、また相手先と初めて通信する場合には相手の確認が必要だが、それ以外は通常のチャットと同じように使うことができる。慣れてくれば暗号化されていることを意識することもない。

(1) (初回のみ) 自分の鍵を生成する (送信側、受信側双方とも必要)
(2) OTRによる通信を開始する
(3) (相手毎に最初のみ) 通信相手を確認する (Fingerprintを確認するなど)
(4) OTRによる暗号化通信を行う

OTRでは最初にメッセージ通信相手の確認 (認証) を行う必要があるが、次の 3つの方法が用意されている。
a. Question and Answer 質問とその答え (当事者しか知らない内容)
b. Shared Secret 共通の秘密 (合言葉)
c. Manual Fingerprint Verification 公開鍵のフィンガープリントを確認

a.の方法は、当事者同士しか知りえない内容について質問し、答えが一致すればOK (これは両方向に行なう)。また b.の方法では、なんらかの合言葉をあらかじめ決めておき、双方がその場で正しく入力する必要がある。c.の方法はPGPでも公開鍵の確認に使われている方法で、電話や暗号化メールなど別の信頼できる手段によって相手の公開鍵の Fingerprint情報をあらかじめ入手しておく必要がある。

なお a.は v3.2.0から、b.は v3.1.0からサポートされた比較的新しい認証方法である (現在の最新バージョンは 4.0.0)。そのため実装によってサポートしている方法には違いがある。たとえば Pidginの OTRプラグインは上記の 3つとも対応しているが、Adiumや IM+は Fingerprint方式のみに対応している。
(注：暗号化メッセージを送るだけであれば通信相手の確認なしでもできるが、その場合には MITM攻撃を受ける可能性がある。)

Adiumによる使い方の例

Adiumで Facebookメッセージをやりとりする際に OTRを利用した例を紹介する。

最初に Adiumで Facebookアカウントを追加すると OTR通信用の公開鍵/秘密鍵のペアが生成される。これはいつでも再生成することができる (図1)。

(図1) OTRの鍵生成

次に通信相手とのチャットをはじめるわけだが、はじめは OTRによる暗号化が無効の状態になっている (図2の鍵アイコンが開いている)。 ここでツールバーの鍵アイコンをクリックして “Initiate Encrypted OTR Chat” を選択すると、OTRによる暗号化通信が開始される (図3)。

(図2) OTR暗号化が無効の状態

(図3) OTRによる暗号化通信を開始

次に送信者、受信者双方が通信相手の確認を行う。図4は相手から送信された公開鍵の Fingerprintを示している (下線部)。これをあらかじめ入手ずみのものと比較して本物かどうかの確認を行う。

(図4) 相手の公開鍵の Fingerprintを確認

これで準備は整った。以降は通常のチャット同じようにメッセージのやりとりを行えばよい。

図5は Adiumでのチャットの様子を示している。赤線で囲まれた中は暗号化されたメッセージだ。同じ内容を Facebookから見たのが図6である。OTRは End-to-Endで暗号化を行なうため、メッセージを復号できるのは鍵を持っているクライアント(今回の例では Adium)だけである。そのため Facebookからは暗号化されたメッセージの中身を見ることはできない。(OTRメッセージが送信されていることは “?OTR” という文字列からわかる。)

(図5) Adium側から見た OTR暗号化通信の様子

(図6) Facebook側から見た OTR暗号化通信の様子

あとログを保存する設定にしていると「オフレコ」にならないので、OTRのチャットログは保存しない設定にすることをオススメする。(図7)

(図7) Adiumの設定画面

まとめ

以上、メッセージングにおいて Forward Secrecyを実現する Off-the-Record (OTR) Messagingについて、その仕組みや簡単な使い方などを紹介した。残念ながらメールのプロトコルで OTR相当のことを実現することはできないが、インスタントメッセージであれば様々なサービスにおいて OTRを使うことができる。NSAによる監視問題をきっかけに、OTRは今あらためて注目されているところだ。EFFなども監視に対抗してプライバイーを守るために OTRの利用をユーザに推奨している。みなさんも一度使ってみてはいかがだろうか。

最後に、今回の記事を書くにあたり、尊敬する友人である辻氏 (@ntsuji) にご協力いただいた。この場を借りて感謝したい。

(参照)
RFC 4880 - OpenPGP Message Format
Off-the-Record Messaging
Ten Steps You Can Take Right Now Against Internet Surveillance | Electronic Frontier Foundation
Encryption Works: How to Protect Your Privacy in the Age of NSA Surveillance | Freedom of the Press Foundation
NSA Surveillance: a Guide to Staying Secure
Opt out of global data surveillance programs like PRISM, XKeyscore, and Tempora - PRISM Break

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がほとんどになるはずです。