LINEのLetter Sealingその後

以前、これまで、LINEのE2EE実装「Letter Sealing」初見LINEのLetter Sealingに関するフォローアップと2回に渡り、LINEのE2EE実装である、Letter Sealing機能に関して取り上げてきたわけですが、以前にも増してメッセンジャーにおけるE2EEが一般的になってきました。以前はE2EEを実装したメッセンジャーアプリはSignalTelegramぐらいしかなかったのですが、今ではFacebook傘下のWhatsappにもSignalと同じ方式のものが実装されましたし、また、Facebook MessengerもまもなくE2EEが実装されるようです。他にもGoogleもビデオチャットアプリであるDuoはE2EEを使用している他、また今後リリース予定のメッセンジャーAlloにもE2EEの実装が予定されているようです。

さて、最近、LINEのEnginners’ Blogにおいてメッセージの安全性のさらなる強化:Letter Sealingの適用拡大という記事が公開されました。内容的にはLetter Sealing機能が更新され、デフォルトでE2EEが有効となり、また、音声やビデオ通話、及びグループチャットにE2EEが使用できるようになった、ということです。

今回の更新で、以前、指摘した、暗号化されているかどうかがわかりにくい、という問題が解決したと思われます。ただ、今回の更新で、暗号化されているのがわかるようになったのですが、以前の記事で「現時点では、Letter Sealingはテキストメッセージと位置情報に対してのみ適用されます。」となっていますが、これが現在どのような実装になっているのかが気になるところです。(今回の記事でこちらの件に関しての言及はなかった。)もし、引き続き、Letter Sealingが「テキストメッセージと位置情報の対してのみ」行われているのであれば、こちらは錯誤を招く表示になってしまいますので、こちらは「何が暗号化されるのか」の詳細を知らせて欲しいところです。

次に、せっかくE2EEを実装しているのだから、もっとアピールしてもらいたいところです。現在、定点観測できるいくつかのトークグループがありますが、半分程度、この機能が有効になっていないグループがあり、そのほとんどが恐らくアプリの更新を怠っているのが原因であると考えます。LINEのユーザーは特にユーザー層が広く、技術的リテラシーにばらつきがあり、こちらは更新を促す施策を是非考えて欲しいところです。

LINEのLetter Sealingに関するフォローアップ

9月1日にLINEのE2EE実装「Letter Sealing」初見という記事を書いて、そこに

(公式情報が投稿され次第、加筆などはする予定です。)

と書きましたが、本日、メッセージの安全性新時代:Letter Sealingという記事が公式ブログのLINE Engineers’ Blogで公開されてますので、公約通り、加筆します。

基本的、公式サイトで解説されているのはLetter Sealingはごく一般的な公開鍵暗号方式が使用されているということです。鍵交換方式はECDH、暗号化はAES-CBC-256HMACと、方式的にはOpenPGPなどで使われている機構とそう変わりません。(ECDHはちなみにGnuPG 2.1で対応しています。)

ここで気になってくるのはECDHを使っているという表記。もし、これを額面通りに受け取るのであればLINEの実装はPerfect Forward Secrecyを実装していない、ということになります。(もし実装しているんであれば、DHEなり、ECDHE使ってますって書くよね?)
PFSは最近のメッセンジャーの暗号化の実装では一般的なもので、セキュリティを高めるのに非常に重要な要素なので、この実装はぜひ検討していただきたいものです。

また、前回の記事でも指摘したように、メッセージが暗号化されているかどうかがわからないのがこのシステムの致命的なところですが、それに関しては修正が検討されているようなのでよかった。

なお、この手の情報を一般向けに取っ付き易く説明するのは非常に骨の折れる話です。LINEのエンジニアのブログではそのあたり、結構丁寧に解説しているので、この点は非常に賞賛できると思います。

LINEのE2EE実装「Letter Sealing」初見

LINE 5.3で追加された機能として、超音波による友達追加の他に、Letter Sealingという機能が追加されているということです。

Letter Sealingの説明は以下のようになってます。

より安全にトークを楽しむためのLetter Sealing機能を追加 (この機能は特定の国や地域でのみ利用可能です)

尚、LINE Engineer’s Blogの記事によると

LINE 5.3.0からは、さらに強化された暗号化方式のE2EE(end-to-end encryption)として「Letter Sealing」機能をご利用いただけます。次回の記事では、「Letter Sealing」について詳しくご紹介します。

とのことですので、そのうち詳細の解説がなされると思うので、この記事はあくまでも現時点で見える範囲で話を進めていることにご留意ください。(公式情報が投稿され次第、加筆などはする予定です。)

この機能、説明が全くなされずに登場した機能でGoogleで検索してみるとベータ版のヘルプらしきものがヒットし、その内容として「Letter Sealingとは」という項目があります。

Letter Sealingとは、トークルームのメッセージにエンドツーエンド暗号化を適用したサービスです。
※エンドツーエンド暗号化(End to End Encryption)とは、サーバー上でもメッセージの内容が暗号化された状態で保存されており、送信者と受信者以外には対話内容を判読できないように設計された通信方式です。

トーク送信者と受信者が互いにLetter Sealingをオンに設定している場合、よりセキュリティが強化されたメッセージを送受信することになりますが、トークルームでは通常どおりトークの閲覧ができます。

なお、Letter Sealingをオンに設定後、WindowsやMAC OSなどPCでLINEを利用する場合は本人確認が必要となります。

End to End Encryptionというのは発信者と受信者の間で暗号化を行う手法のことで、正しく実装されている限り、第三者による監視が困難になる通信方式です。前にタイマートークというのが実装されましたが、方式的にはそれと類似しているようです。(ただし、タイマートークは日本、中国では使用できないようです。)

Letter Sealingの設定は、トーク設定画面から行えるようになっていました。(いつの間にか行えるようになっていました。尚、「特定の国や地域」がどこを意味しているのかはわかりません。)

Letter Sealing設定
Letter Sealing設定

説明には「メッセージは高度な暗号化により保護されます。Letter Sealingは友達がその機能を有効にしている場合に限りトークで利用できます」とあります。この説明によると、トークで何らかのオプションが有効になるかと思ったのですが、双方でこの二つをオンにした状態でメッセージを送信すると、普通に送受信されます。(暗号化のオプションなどは見当たらず、ただ単に通常のメッセージとして表示される。)

ところが、Chrome版のLINEでログオンすると警告が表示されます。

Chrome版LINEでの表示
Chrome版LINEでの表示

Letter Sealingが有効になっていると、一部のメッセージが表示されない場合があります。
この機能を無効にするには、携帯電話版LINEで[設定]>[トーク]>[Letter Sealing]に進んでください。

つまり、Chromeアプリ側では暗号を復号化する鍵を持ち合わせていないので開けないということでしょう。これはタイマートークでもそうなので想定内でした。反対にこれで開ける作りになっていると実装を疑わざるを得なくなります。(なぜなら、もしChromeアプリ側で復号が可能である場合、サーバを経由して秘密鍵を転送していることになるので、結果としてサーバ側がメッセージを読むことができてしまうわけです。)

上記ですでに送信していたメッセージは次のような表示に置き換えられていました。

ChromeでのLetter Sealingメッセージ表示
ChromeでのLetter Sealingメッセージ表示

[Letter Sealing]

ご利用の端末では[Letter Sealing]に対応していないため、このメッセージを表示できません。
モバイル端末の[設定]>[トーク・通話]で[Letter Sealing]の設定を変更してください。

つまり、先に送ったメッセージは暗号化されて送られていたわけです。つまり、本質的にはLetter SealingはOpportunistic Encryption(日和見的暗号化)ということになるようです。(暗号化できる場合は暗号化する方式、この方式自体はメールサーバ同士の通信などにも使われています。)ただいくつかの疑問というか問題点が……。

  1. ユーザーはどうやって暗号化された、ということを確認するのか? 方式的に双方が有効にしていないと作動しない機構であることもあり、暗号化されるのであればその旨が通知されなければ使い物にならないのではないか。。(鍵マークなどを表示した上で、暗号化が有効になった時点、無効になった時点でユーザーに告知すべき。これをしないと全く意味がない。)
  2. どのようなペイロードが暗号化されるのか。当該のメッセージが暗号化されていることを確認する少し前に送ったスタンプや写真はChromeアプリからも読み取ることができた。(つまりスタンプや写真に関しては暗号化されていない。)このあたりも全くユーザーに告知されていない。
  3. 複数人のトークの場合は暗号化されるのか。またはその場合はどのような方式になるのか。こちらはちょっと機構的に複雑な部分。でもTextSecureでは実現できてるけど……。

詳細については公式の解説を待ちたいところですが、ぱっと見たところではちょっと疑問が残るシステムでした。特にユーザーにそのステータス(状態)の表示がないのはまずいです。タイマートークであればタイマートークを使っていることが一目瞭然にわかりますが、今回のLetter Sealingでは、何が、いつ暗号化されているかという表示が全くないですし、そういったことが明示されないのが致命的です。また、設定方法に関しても、設定画面以外のところから有効にできるようにしないと、わざわざトーク設定まで行って、Letter Sealingをオンにするユーザーはまずいないのではないかと思います。

LINEの超音波による友だち追加を分析

LINE 5.3で超音波やBluetoothにより友だちを追加できる機能が装備されました。どのような仕組みになっているのかを検証してみました。

先ずは、信号を可視化するため、スペクトラルグラム及び、スペクトルを取ってみました。

LINE友だち追加信号のスペクトルグラム
LINE友だち追加信号のスペクトルグラム
LINE友だち追加信号のスペクトル分布
LINE友だち追加信号のスペクトル分布

音声出力を直結して信号を採ろうかと考えたのですが、ヘッドフォン端子が使用されているとこの機能が有効にならないようです。(そのため、マイクを近づけて録音しました。)

調べると、18976Hz、19576Hz、20199Hz、20799Hzにピークが現れているようです。全て、可聴音ではないので、聞こえない音ですが、耳のいい人はかすかに聞こえるかもしれません。

そこでこれを可聴域に変換したものを作成してみました。

複数の信号が重ねられており、内容に関しては判明していませんが、恐らく、FSKで信号をコーディングしているものと考えられます。同様の技術は「JR東日本アプリ」や「ぐるなびタッチ」などのアプリで使用されており、これらは「Air Stamp」という技術を使っているようですが、Air Stampは事業者が信号を発生させ、それをスマートフォンなどで読み取らせ「チェックイン」するスタイルのシステムであるようで、少し違ってそうです。どちらかというと、システムとしては双方向通信が行われているものではなさそうですが、超音波によるネットワーキングが近い感じです。(これらに関してはGigazineさんがカバーされています。)

尚、超音波ではなく、可聴音を使用した符号化に関してはアマチュア無線などで、RTTYPSK31などのデジタル変調として日常的に使用されています。(尚、これらの変調を聞くと、上記の可聴音に変換したようなものに似た音声が聞こえます。

追記:パターンを見ると変調方式は恐らくFSK。それぞれ2つずつの周波数を使用して、2つの信号が出ているようです。なぜ信号が複数出ているのかはわかりませんがその送出パターンが途中で反転していることを考えると干渉による影響を軽減させるために行われているのではないかと考えます。

LINEのタイマートークで思うこと

LINEに新しく、タイマートークという機能が追加されました。

現在、「日本、中国以外でご登録いただいているお客さま」以外にしか使用可能になっていないそうですが、そのうちオープンになるんじゃないでしょうか。(中国では永遠に使用できないかも知れませんが)

どういう機能かというとSnapchatのように制限時間をつけたメッセージを送れるということです。(当然、両環境が最近のバージョンかつ上記の地域制限に引っかかっていない地域のユーザーである必要があります。)

使用を試みると以下のような表示がでます。

Screenshot_2014-07-31-21-24-22

これを見るとエンドツーエンドで暗号化しているようです。メニューにも暗号化キーを表示できるようになっています。見ると128ビット長のユーザー固有の鍵が使用されているです。

Screenshot_2014-07-31-21-24-36

タイマートークのメッセージを受信すると以下のようにタイマーメッセージであることが表示されます。メッセージの内容を通知する設定になっている場合もタイマーメッセージの場合、内容は表示されません。

Screenshot_2014-07-31-21-25-33

メッセージをタップすると双方でカウントダウンが表示されるのが確認できます。この長さは2秒から1週間まで選択できるようになっているようです。

Screenshot_2014-07-31-21-25-45

さて、この機能なのですが、一応エンドツーエンドをLINEで実現しようという機能は評価できるのですがいくつか思いつく問題や懸念としては……。

  1. 暗号が正しく使用されているか、また運営会社や当事者以外の機関(政府機関を含む)の鍵に対して勝手に暗号化を行っていないか
  2. 暗号鍵が変更できない使用になっているが、乱数などでちゃんと生成されたものなのか
  3. メッセージはきちんとソルトされているか

1に関してはこれはクローズドソースの宿命なので、回避のしようのない問題と言えます。これは別にLINEに限らずWindowsなどのOSを含め、どのようなソフトでも当てはまります。
2に関しては、いくら暗号を使用していたとしても暗号鍵が予想できる情報から推測できるものが生成されるような仕様になっていると無駄になってしまいます。また、正しく実装された乱数から取り出されたものであっても、変更が行われない仕様になっていると暗号鍵が漏洩した場合、役に立たなくなってしまいます。これに関しては手動で鍵を再生成し拡散できるような仕組みが欲しいところです。どちらにしても署名目的には使用していない仕様と思われますので、鍵を定期的に再生成するぐらい仕組みでもいいかと思います。
3に関しては特にLINEの場合、既知のスタンプなどパターン化されたメッセージが頻繁に使用されるシステムのため、ソルトがきちんとなされていないとリプレイ攻撃などが容易に行われてしまいます。そのため、他のソリューション以上にソルトが重要であるかと思われます。

尚、評価できる点としてはスクリーンショットの防止・通知など幻想のセキュリティが想起されるような実装を行っていないところです。Snapchatではこれが行われていますが、実際のところその通知がないからと言ってスクリーンショットが撮られていない、という保証はありませんし、基本的に他のユーザーに送られた場合、送られた情報はそのユーザーがどうとでもできる、という前提に使われるべきです。将来的にこれらが実装されるのかは分かりませんが、現時点で敢えてそれらに関して対策を行っていないのはある意味まともとも言えるかも知れません。ただ、ヘルプなどでスクリーンショットなどの撮影が可能なので、タイマーメッセージで送付先ユーザーがそのメッセージを受け取った後は必ずしも安全でない、ということは示されるべきであると考えます。