TextSecureの目標は「経路末端までのセキュリティ、否認性、前方秘匿性、将来の秘匿性のすべて」を提供することである。具体的には、可能な限り短い時間だけ鍵情報を保持するメッセージストリームを二者の間に構築するということを目指す。将来に鍵の危殆化があっても、現在観測されたトラフィックを復号化できなくするのだ。

以下にSignal Protocolの批評的分析を羅列してある。実装の構造を研究し、発見した欠陥を記述し、上述の目標がどれほど実現されているかを評価するものである。まず仕組みの説明をしてから、より詳細な分析を続けることにする。

用語

TextSecureは、今ではSignalと呼ばれているアプリに与えられた名の一つだ。コードも文書も一貫してTextSecureという名を使っている。一貫性を保つため、システム全体をTextSecureと呼ぶことにする。

ただ実際には数々の異なるものが含まれている:

TextSecure Server、あるいは最後にリンクした白書ではTSと呼称されるものだが、これはシステム全体でステートを整合させる中央サーバだ。

Signal ProtocolはFacebook Messenger から Google Alloに至るまで各種メッセージングアプリで使われる、より一般的なプロトコルのことだ。以下に説明される機能を備えるが、メッセージの配送経路やメタデータ追跡は実装の自由に任せている。

Signal アプリは、以下で分析するTextSecure Serverポリシーを用いてSignal Protocolを実装するモバイルアプリだ。これが同プロトコルの最初の実装である。

構造

TextSecureは、非同期整合性に焦点を当ててOff-The-Recordというチャットプロトコルを改造したものだ。OTRが対話的ハンドシェイクを必要とする一方、TextSecureは不確定な遅延を認めない。メッセージを送れるようになるまでアプリを表示したままにしてハンドシェイクを遂行しなければならないというのであれば、ユーザ体験はひどいことになる。

そうではなく、通常の鍵交換においてサーバが果たす役割の部分だけ、将来のクライアントが取得しに来るよう中央サーバに格納される。このサーバは、すべてを復号化できる鍵情報は預けておかない、信用なし経路となる。すべての暗号化は末端どうしだ。

暗号

TextSecureは暗号学の基礎のほんの一部を使うものである。公開鍵暗号は楕円Diffie-Hellmanを通し、Curve25519を用いて実行される。AESがパディングなしカウンター(CTR)モードとサイファーブロックチェーン(CBC)モードの双方で対称暗号に使われる。HMAC-SHA256がメッセージ認証に使われる。これらが信頼の基礎(TCB)である。

ダブル ラチェット:

TextSecureの暗号化エンジンの中心部はAxolotlダブルラチェット・アルゴリズムである。大まかに言うと、一方向にだけ回ることのできるラチェットが二つあり、一つは受信ラチェット、もう一つは送信ラチェットである。この構造により、鍵交換の前半を保管しておいて、後から非同期的に再生し完全なハンドシェイクを得ることが可能になっている。

受信ラチェットはメッセージが受信されるときに使われるが、そこには次の鍵交換のための新しい材料が含まれていなければならない。この材料が後ほど暗号化やメッセージ認証に使う対称鍵の生成に用いられる。

送信ハッシュラチェットは前回の整合性ある共有秘密から生成された鍵ストリームを使って新たな鍵セットを生成する。このラチェットは、受信ラチェットが進んで共有秘密が変化するとリセットされる。

ここで注目すべきは、メッセージを送信するために送信者が待つ必要は一切ないということだ。いつでも送信の第一歩を踏み出すことができ、その一歩は必ず有限の時間で終わる。メッセージはすべて異なる対称鍵で暗号化されるが、これにより、ある時点の鍵は、どちら側のデバイス上のものであっても、過去に送信されたメッセージを復号化するためには使えないことになる。(ただし後で一つ警告がある。)

プロトコル

フェーズ1: TextSecure登録

登録は、クライアントに言って、連絡用の電話番号をサーバに教えてもらうことから始まる。また同時に、トークンを通話とSMSどちらで受け取りたいかの希望も登録してもらう。このトークンが持ち主の証明となり、TextSecureで情報を登録できるようにしてくれる。

クライアントはメッセージ認証と暗号化の対称鍵('signaling'鍵)、および長期公開鍵を送る。

また、複数のプレ鍵も送信する。これはクライアントが受信者になる時の鍵交換の半分、クライアント側部分の使い捨てコピーである。こうして保管されているプレ鍵のおかげで、将来の送信者はクライアントの応答を待つ必要もなく鍵交換を完了でき、こうして遅延を劇的に減らすことができる。クライアントは「最後の手段のプレ鍵」もアップロードするが、これは最後に使われ、受信者が新しいプレ鍵を追加するまでのセッションでずっと共有され続ける。

他のクライアントからも使われるプレ鍵に頼ることについてSignalが警告をしないというのは、筆者の意見では、理想と程遠い。

クライアントは次にGoogle Cloud Messagingに登録して、登録 IDをTextSecureに出す。このTextSecureへの登録には、クライアントがSMSを受け取りたいかデータだけにしたいかの情報も含まれる。

フェーズ2: 鍵の比較

TextSecureはクライアントどうしがお互いの長期鍵のフィンガープリントを比較して本人確認できるようになっている。鍵をQRコードとして表示して便利に検証できるようにする機能も含まれている。

フェーズ3.1: 最初のメッセージ 送信

送信者は、まず相手のプレ鍵を要求し、プレ鍵インデックス、プレ鍵、登録 ID、長期公開鍵をもらう。これらを使い、HKDFという鍵派生アルゴリズムを通して共有秘密を取り決める。この秘密情報をルート鍵と呼ぶ。

このメッセージだけの一時鍵ペアが生成される。ルート鍵を使ってHKDFで新しいルート鍵とつなぎ鍵を派生させる。このつなぎ鍵は、暗号化とMACの鍵を生成するのに使われる。

最後にAES カウンターが初期化される。カウンターは二つある: ctrとpctrだ。ctr カウンターはメッセージ送信ごとに増える一方で、pctr カウンターは、最後の既読メッセージの番号を保持する。これにより、受信者側にバラバラの順番で届いたメッセージを正しく並べ直すことができる。

これらを使って相手にメッセージを暗号化し、それをSignal サーバに送る。このメッセージには、相手が鍵交換ハンドシェイクを完了できるだけの必要情報が含められている。

Signal サーバはGoogle Cloud Messenger登録 IDが件の電話番号に合っているかチェックし、メッセージを'signaling'鍵で暗号化してからクラウドサーバに送る。この遠回しな方法により、Google Cloud Messengerがメッセージの送信元を知らずにいることが保障される。

フェーズ3.2: メッセージ受信

受信者はプレ鍵インデックスを受け取り、送信者がどのプレ鍵を使ったかをそれで調べる。そして送られてきた情報を使ってハンドシェイクを完了したり送信者と同じルート鍵を持ったりする。送られてきたメッセージを復号化するために使う鍵は、このルート鍵が生成する。

フェーズ4: 追伸メッセージの送信

相手が返信する前に、もとの送信者から続きのメッセージを送りたい場合は、新しいつなぎ鍵を生成して、これを使って新しい暗号化およびメッセージ認証の鍵を得る。

フェーズ5: 返信の送信

受信者が返事を出したい時は、まず新しい一時鍵ペアを選ぶ。送信者の一時公開鍵と自分の一時秘密鍵を使って、新しい共有秘密を生成する。これを使って新しいつなぎ鍵を得て、そこから新しい暗号化と認証の鍵を得る。これを使ってメッセージを暗号化し、さきほどの新しい一時公開鍵と一緒に送信する。

既知の問題

鍵の提出

TextSecureは、サーバとクライアント間の共有秘密、いわば機械生成パスワードを使って、新しいプレ鍵のアップロードを認証する。これは送信メッセージの認証にも使われる。このパスワードを漏らしてしまうと、それだけでメッセージの送信も鍵アップもそのユーザになりすましてできてしまうことになる。エキスポート機能があった頃はTextSecureクライアントを別のスマホに移行することができたが、この機能は削除された。エキスポート情報には機械生成パスワードが含まれていたからだ。この平文バックアップはデバイスのSDカードに置かれていたので、他のアプリから読むことができたのだ。

この機能はそれ以来削除されたままだ。なくて困る人がいるとしても、これはユーザビリティの問題ではなく、現実の問題であり、それに対する後ろ向きな対策なのである。

未知の鍵共有 (UKS) 攻撃

この攻撃は偽配送の一種だ。攻撃者がUKS攻撃を実行すると、ある送信者が攻撃者に向けて送ったつもりのメッセージが、攻撃者から別の人(標的)へのメッセージとして送信される。

これは能力のある攻撃者にとっては簡単にできる。TextSecureサーバ上にある自分の公開鍵を、標的の公開鍵に変えればいい。これは自分の電話番号を再登録すればできる。送信者はQRコードを使って、相手のフィンガープリントが合っていることを検証できるが、これが本当に標的の鍵のフィンガープリントになるのである。

それから、今度は送信者のアカウントを再登録して、その検証 SMSか確認通話が送信者に到達しないよう横取りしなければならない。これは太っ腹に権限を与えられた人には造作もないことだ。こうして、送信者として認証し、既知の署名つきメッセージを送信できるようになる。

この攻撃はTextSecureでは解決されていない。プレ鍵の署名は追加したが、まだ暗号学的にIDと関連付けられているわけではないので、奪われて再生される危険がある。

できることがあるとすれば、送信者と受信者の双方がメッセージの暗号化された本文内で言及されるようにすることなどだ。

目標達成率

TextSecureはその構造のおかげで前方秘匿性を獲得している。前方秘匿性(forward secrecy)は、もし長期公開鍵が安全なままであれば、ある時点の対称鍵が漏れても、そのセキュリティ突破は限定的な時間範囲にしか有効でないとする。新しいラチェットのそれぞれに公開鍵が必要であることから、これは達成されている。

完全前方秘匿性(perfect forward secrecy)は、クライアントの持つある時点の鍵が奪取されても、それ以前に送信したメッセージの復号化が不可能である性質と定義されている。このことはTextSecureのwire protocolにより施行されるが、少々ことば遊びに入ってくる。というのも鍵はデバイス上にのみ格納されているので、アプリ上の他の鍵にアクセスすることなく鍵が暴露されることはありそうにない。長期鍵だけではメッセージを復号化できず、ラチェットのステートに対応する一時鍵が必要になるが、これはそのスマホから引き出すことができるので、送信したものの返信されていない(前回のラチェットを使用した)メッセージを復号化できる。これは技術的に言えば「以前の」メッセージの暴露である。

否認性(アリバイ)はさらにあやふやだ。ある特定のメッセージについて、それはだれにでも作成できたのだと言うことは可能だが、その一方で、プレ鍵は公開されているので、TextSecureの中央集中構造が脅威をもたらす。TextSecureサーバは認証とメッセージ転送をするものだが、それを記録することもできる。内容は末端どうしで暗号化されているとはいえ、メタデータは違う。

Sources

Analysis Whitepaper:

http://ieeexplore.ieee.org/document/7467371/

Marlinspike, Moxie (30 March 2016). "Signal on the outs ide, Signal on the inside". Open Whisper Systems. Retrieved 31 March 2016. https://whispersystems.org/blog/signal-inside-and-out/

Posted by Alexander Kyte at 11:47 PM

Permalink | 記事への反応(0) | 12:31

2016-07-16

■断言はしないが、チャット ボットも関連ビジネスも機会はあるよ

はじめに

先日、はてなの匿名記事で大きくバズってる記事があったので、拝見したが、何とも言い難い気持ちになった。

匿名記事なので、あえて私についての説明を加える必要はないかと思うが、某記事と近い立ち位置であることはご理解頂きたい。

チャットボットに関する議論の方向性が見えないのは、チャットボットというワードによって、様々なものを一緒くたにしてしまっているからである。

現状は、切り分けると実に多様である。

チャットのUIそのものの「チャット」なのか、Facebook MessengerやLINEなどのプラットフォーム依存の「チャット」なのか。

人工知能を用いた「ボット」なのか、単純に応答を返す「ボット」なのか。

今回は、プラットフォーム依存の「チャット」、単純に応答を返す「ボット」という意味でのチャットボットの実用性についてお話したい。

そもそも、昨今のチャットボットブームというのは、Facebook MessengerやLINEなどがプラットフォームを公開したことに依るもので、そこに新規性があるはずで、今しなければいけない議論はここにある気がしている。

チャット ボットはユーザーにフィットするか

よく言われるのが、ユーザーは使うのかどうか、という話であるが、プラットフォームがβ版の最中で、今これを議論するのは時期尚早である。

だが、在米時代にUberのボットを使ってみたり、在中時代にWeChatで色々とボットを試してみると、これがかなり便利なのである。

私はそもそも電話が嫌いであるし、ウェブやアプリを横断するのも面倒くさい。

その中で友人などとメッセージをやり取りし、そこからアプリを動かずに予約をしたり、企業に問い合わせたり、というのは手間が省けて実に良い体験であった。

では日本ではどうだろう。

ここは、まだユースケースが出ていないことが問題である。

だが、若者世代含め、チャットアプリが生活の大きなパイを占める時代においては、当然求められても納得出来る。

であるからして、予約や定期的に購買するEC、デリバリーサービスやメディア諸々、チャットだけで完結するようなユースケースは必ず出てくると思う。

そういったケースが増えていくと、「これはなんでチャットで出来ないんだ」という時代が来てもおかしくはない。

いろんなものがネットで可能になった時に、「なんで今の時代にネットで出来ないんだ」と思われたと同様に、だ。

「チャットじゃなきゃダメなんですか？」ではなく、「チャットじゃダメなんですか？」という問が来る日もそう遠くはないかもしれない。

課題

一方で、課題は山積みである。

今回、人工知能型ではないものに重点を置いたのは、人工知能型には課題が多すぎるからである。

自然言語処理も精度は高くないし、無論、感情を読むなどはまだ先の話になるだろう。

そして、まるで人間ですよ、というものに対し、ユーザーが対人コミュニケーションを望むのは間違いない。

人間に話しているのに、およそ意味不明な回答が来たらユーザーは離脱するだろう。

一方で、そもそも人間ではなくただのシステムだと認識していたらどうだろう。

今は、ユーザーも企業も、雑談や人間らしさはさておき、ちゃんと言ったことをこなすコマンド型のボットに期待すべきだ。

いわば、アプリをチャットのUIにして、コモディティ化しているプラットフォームで公開する、ということだ。

今までユーザーもアプリに対して人間らしさ、などというものは微塵も期待していないはずで、そのようなボット像を目指すべきではないかと考える。

また、ユーザーに広く使われるためには、チャットボットと言えども、UXは非常に大切である。

この点においては、プラットフォームが解決しようと頑張っている。

FacebookがQuick Replyという機能を実装したことから見えるのは、

⑴そもそもユーザーの発言に揺れが出ないように、最初から選択肢を用意しよう

⑵ユーザーがテキストをタイプする手間を省いてタップだけで済むUIにしよう

ということであり、チャットボットが広く使われる上でのUIを見越していると思われる。

その上で、企業側も前述のようにプラットフォームが用意したUIをいかにフル活用して、いかにユーザーが使いやすいものを作れるか、が非常に重要だと考える。

最後に

多様なものが混合しているワードを漠然と差して、「これはない」というのは暴論だろう。

1VCさんが、この領域は絶対ない、というのは新規投資先スクリーニングに有用だと思うが、それならば実名にし、そのVCではチャットボットサービスには投資しません。

と言ってしまった方がコスト削減になるのではないだろうか。3割もの方がチャットボットサービスについて話し、毎回同じ議論をしているのだとすれば、それこそ無駄である。

なんなら、事業内容を聞いて、「チャットボット」というワードが入れば「事業内容を変えなさい」と返すチャットボットでも作ってみてはいかがだろうか。

こういった機会は、毎回必ず様々な議論を生み出すが、全員の意見が一致しないからこそ、投資の価値があり、それを見抜いたものが勝つ業界だと思っている。

だから、是非ともチャットボットサービスを考えている皆さんは、ちゃんと自身のサービスの価値を見極めた上で、頑張ってほしい。

チャットボットが来るかどうかは分からないので断言はしない。

だが、その不確実さこそ、次なるサービスが生まれる絶好の機会ではないだろうか。

Permalink | 記事への反応(2) | 07:26

2015-10-27

■Facebookで写真を3人に共有したら友達を1人失った話

写真を友達と共有したいときどうしてる？

たくさんあると思うけど、今回僕が使ったのはFacebookの限定公開機能。

共有したい友達選んで普通にタイムラインアップするやつ。

たった3人を公開範囲に指定して写真をアップしたら、

Facebookじゃ拡散する（？）からやめろ！と

前代未聞の大喧嘩につながったという悲劇。

とある会への参加

先日とあるAさんが主催する会があり、僕は友人Bとほか数人で参加した。

その会の最後でこんな感じのアナウンスが。誰も詳しくは覚えてない。

「この場で撮影した写真はSNSに投稿せずに、LINEとかで交換してください〜」

なるほど、不特定多数に公開しちゃダメなわけだ、と僕は解釈。

この場にいる人であとで写真交換しなきゃなぁ、と。

翌日、身内メンバに写真を共有

そして翌日、写真を整理し...

参加した身内メンバーの共通連絡網である Facebookに、公開範囲を限定して写真をアップしてみた。

たったの3人への公開。

Facebookのメッセージってたくさん立ち上がるとウザいし、タイムラインでも良いかな、とタイムライン上への送信。

（ちなみに一緒に参加した友人にLINE IDを知らない人もいるし、今までFacebookのみで連絡してきた仲間だ。）

謎のメッセージ

FBにアップしてから数時間後...友人Bからメッセージが届く

B「SNSには上げないでって言ってたよ」

お、おう、確かに。公開範囲分かってないのかな？と思ったが…

B「限定公開なのは知ってるけど」

？？？

なるほど限定公開だろうがSNSを使って写真をシェアするということが、そもそも嫌なのか。

最近はFacebook使って仕事のやり取りすることが多いし、

この辺りのハードルが僕の中では低くなってたかもしれないなぁと思った矢先。

B「LINEは投稿と言うか」（言うような言わないような）
B「FBが乗っ取られたらどうするか」（セキュリティの話はLINEにも言えちゃうっしょ）
B「Aさんの意図に反さないか」（Aさんその辺よくわかってると思うし、意図汲み取ろ？）
B「FBは拡散する恐れがある」（いやそれお前+2名が余計なシェアとかしたらやん！）
B「LINEは一対一のコミュニケーションに特化してる」（それ、使い方によらないかな）
B「Facebook messengerなら良いと思う」（やってることあまり変わらないと思うんだけど）
※括弧内は最後まで伝わらなかったが僕の心の声

こんなメッセージが。

道徳、セキュリティ、サービス性、全方位からとにかく投稿をやめさせたいらしい。

しかし結局何が言いたいのか分からない。

このままではこの時代に、ディスクでデータを渡さなければならない…。

かれこれ2時間会話を続け…要はこの認識に差があったことが問題らしい。

B「"SNSへの投稿"の意味は、Facebookやtwitter、LINEのタイムラインにデータを流すこと」
B「LINEのトークやFacebookのメッセージ、twitterのメッセージでデータを相手に送ることとは違うと思う」
B「俺の見方をする人は一定数いると思う」

公開範囲とか、不特定多数への公開とかは全く関係がない「SNSへの投稿」という文字列に囚われた思考。

DropboxもHangoutもLINEも「投稿」じゃないからOKということだそうだ。

しかも、同じ考えを持った人は（Bさんによれば）少なからずいるらしい。宗教かな？

今後はBさんとのSNSでの関わり方には気をつけないとな…と。

実際そんな人がたくさんいるのか知らないが、本当にあった怖い話。

Permalink | 記事への反応(1) | 08:17

「Facebook messenger」を含む日記

■結局10代はLINEをどういう目的で使っているのか？

■🌚なぜ🥬LINEを使っているのですか？

■マジでLINEとかいうクソボケサービス使うな

■欧米で流行しているWebサービス

Hangout(Hangout Chats)

Gsuite(Google Documents)

JIRA

Foursquare/Swarm

MyFitnessPal

その他の動き

■How the Textsecure Protocol (Signal, WhatsApp, Facebook, Allo) Works

ダブルラチェット: