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のユーザーは特にユーザー層が広く、技術的リテラシーにばらつきがあり、こちらは更新を促す施策を是非考えて欲しいところです。

なぜGrub2の認証脆弱性は大きな問題ではないか

Linuxのブートローダー、Grub2にバックスペースを28回押すとレスキューシェルに入れてしまうバグがあるということがこの数日報道されています。

脆弱性があるということ自体に問題があるということを否定するわけではありませんが、まず、Grub2を含む、ブートローダーの認証を過信するのが問題です。実質的にブートローダーの起動パスワードが入力できる状態であるということは即ちハード自体へのアクセスがあることを意味します。ハード自体へのアクセスが行えるのであれば、ブートローダーをUSBドライブ経由などから読み込ませて起動すれば、レスキューシェルなど、簡単に実行できてしまいます。ハードのアクセスが物理的に行える以上、この脆弱性が存在しようがしまいが、本質的にはセキュリティには全く影響しないのです。

そのため、セキュリティ問題としてこの問題を解消するには次のような施策が必要になってきます。

  • ハードへの物理的なアクセスを制限する。
  • パーティションを暗号化する。

尚、Grub2の認証機能自体、そもそも幻想のセキュリティを提供する形になってしまっていますので、本来はこんな機能自体削除しまったほうがいいぐらいです。(カジュアルな運用でレスキューシェルへ簡単にアクセスできてしまうこと自体が問題になるのであれば、ブートローダーからレスキューシェルは取り外して、必要に応じてそれを有効にしたブートローダーを外部メディア経由で起動するほうが余程マシな運用です。)

OnionShareを使用した安全なファイル共有

OnionShareを使用することにより、簡単にファイルを共有することができます。

OnionShareはTor秘匿サービスの仕組みを使用しています。秘匿サービスを使用することにより、検閲システム等に影響を受けにくく、また、点から点を暗号化された接続で結ぶことにより、第三者にファイルを預けることなく、Torのネットワークを介して、データを転送することができるようになっています。

OnionShareを使用するのに必要なものは次の二点です。

上記をダウンロードし、インストールした後は、まずはTor Browserを起動します。

TorBrowser

Tor Browserが正常に起動したのを確認した後、OnionShareを立ち上げます。

OnionShare起動後

OnionShareでファイルを選択します。

OnionShareファイル追加後

Start Sharingボタンを押します。(●表示が黄色になります。)

OnionShareファイル公開準備中

●が緑色になったら表示されている.onionアドレスを読み、受信者に伝えます。(そのままコピーすることもできます。)

OnionShareファイル公開

受け取り側はTor Browserを開いて提供された.onionアドレスを開きます。

TorBrowserで表示したOnionShare

ダウンロードのボタンを押すとダウンロードが開始されます。尚、受信者側で次のような警告が表示されることがあります。(既定で表示される。)

TorBrowserダウンロード警告

これはファイルが持つ潜在的な危険性(例えば、実行ファイルなど)を警告するものです。ZIPファイルにはそのようなファイルが入っている可能性があるため、この警告が表示されるようになっています。ダウンロードするだけでは危険はありませんが、内容物に含まれるファイルが匿名性を損なわせる可能性があることを警告している文言です。

OnionShareダウンロード完了

既定では受信者がダウンロードを完了すると、自動的に公開は停止されます。Stop sharing automaticallyのチェックを外すと自動的に停止されないので、複数の人にダウンロードしてもらう場合は、このチェックを外す必要があります。(ファイルの公開が停止された後に、再公開すると別のアドレスが生成されます。)重要なのは相手がダウンロードを完了するまで、OnionShareの共有は有効にしておく必要があります。

このようにファイルを手軽に転送できますが、特徴として以下が挙げられます。

  • 点から点への暗号化接続
  • Torに接続できている限り、ポート転送などの設定は必要なし
  • サイズの制限なし(システム上のファイルサイズの制限などに依存します。転送速度は遅めになります。)
  • Hidden Serviceが備える高い匿名性(ただし、その匿名性は当然.onionアドレスを知らせる手段により変化します。)

恒久的に、特に不特定多数にファイルを提供する場合、Webサーバを使用したHidden Serviceサイトを構築する方がいいですが、手軽にファイルを特定の相手に転送するのには便利かと思います。

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をオンにするユーザーはまずいないのではないかと思います。

Rhodanthe CA設置について

ホスティング会社が最近SNIながらもSSL/TLSに対応しました。ということで、管理中のサイト群も暗号化に対応するのですが、一つ問題としては証明書の管理が非常に大変なことでした。現状、HidekiSaitoCom PKI情報にも記載しているようにいくつかのサイトにおいてはStartSSLより無料で入手した証明書を使用しています。しかしながら、StartSSLは証明書の発行に制限がついており、また、破棄証明の作成に費用がかかるシステムになっています。そのため、全てのサイトに対してこの証明書を入手するのは破棄が必要になった場合の費用及び、破棄を行わない限り、代わりの証明書を得ることができないという関係上、何らかの不都合が生じた場合、非常に問題が発生する可能性があります。かと言って、ほぼ収益が0のサイトで証明書の費用を捻出するのは大変です。将来的にはLet’s Encryptプロジェクトが解決しうる問題であるかも知れませんが、一般公開が始まった後でもホスティング側での対応も必要であり、使用できるまでにそれなりの時間がかかるものと思われます。

そこで、現状の打開策としては自己証明書(いわゆるオレオレ証明書)を使用する方法もあるのですが、ここはGnuPGをプロモートしている者として、外部的にも検証が可能である方法を考えたすえ、実験的にRhodanthe CAを設置しました。(要はオレオレ証明書ならぬ、オレオレ認証局とOpenPGPの合わせ技です。ちなみに高木氏の区分でいくと第二種オレオレ証明書+ぐらいのものになるかも知れません。)

Rhodanthe CAの構成図
Rhodanthe CAの構成図

通常の認証局と違い、ルート証明書の別途導入が必要であるなど、サイトの正当性を保証する性質のものではありませんが、オポチュニスティックな暗号化を使用できるように今回、この設定を行いました。機能としてはルート認証及び中間認証、及び証明書破棄リスト(CRL)の利用ができるようになっています。尚、Let’s Encryptにおいてもフリーで自動的に証明書が得られる形になるようですから、サイトの認証などはほぼないものの、恐らく正当な(素の状態で警告が出ない)証明書を使用するシステムとなるかと思いますが、正当性証明に関してはドメイン名以上のものは行われないと思われますので、その正当性の信頼性は恐らくRhodanthe CAよりも少し良いぐらいになるかと思われます。ともあれ、恐らく、今後はネット上の暗号化された通信の割合を増やす、ということが主な課題になってくることから、これまで通常の証明書が担ってきた、サイトの正当性の証明はExtended Validation証明書が主流になってくると思われます。

ちなみにGoogleなど、大手の会社は自社で認証局を持っています。この場合は、正当なルート認証局より認証局自体を認証してもらう(つまり、ルート認証局の下に属する中間認証局になる)方式になっています。これはもちろん非常に高価であり、またこのような形で、正式な認証局として設置するには証明局運用規定を設置するなど、個人じゃ到底無理なレベルですので素直に諦めました。(確か、州によっては免許も必要だったと思います。ワシントン州は必要みたい。)