LINE： Letter Sealing による End-to-End 暗号化

no extension

以前の「タイマートーク」のように「どうせ日本リージョンのユーザには関係ない話だろう」と思っていたら，日本でもやるらしい。 LINE は捨てたので完全に見落としていたのだが，既に9月時点で実装されていたようだ。

Letter Sealing に関する詳細情報も公開されている。

まぁ Google の Hungout や Facebook の Messanger よりマシになったとは言えるだろう。 上の記事で説明されている仕様は以下の通り。

  • エンド・ユーザ間の Diffie-Hellman 鍵交換。アルゴリズムは ECDH/256bits。ただし ephemeral かどうかは不明1
  • メッセージの暗号化には上の鍵交換で生成した AES/256bits 鍵を使う。モードは CBC
  • HMAC によるメッセージの完全性の担保2

お気づきと思うが，このままでは鍵の真正性を証明（certification）できない。 相手から送られて来る公開鍵情報を無条件に受け入れてしまう。 ぶっちゃけて言うなら LINE サーバ上で中間者攻撃（man-in-the-middle attack）が可能ということだ3。 「LINEのE2EE実装「Letter Sealing」初見」によるとクライアントごとに異なる鍵を生成するようなので4，なおさら鍵の証明が重要になってくると思うのだけど。

どうも最近は「暗号鍵がユーザに見えるのはダサい」みたいな風潮があるけど，公開鍵暗号方式を使うなら鍵の証明と管理の scheme が生命線になるので，これを怠ると今回のような中途半端な実装になってしまう。

昨年， EFF が安全なメッセージング・アプリの条件を示した。

条件は7つ。

  1. Encrypted in transit?
  2. Encrypted so the provider can’t read it?
  3. Can you verify contacts’ identities?
  4. Are past comms secure if your keys are stolen?
  5. Is the code open to independent review?
  6. Is security design properly documented?
  7. Has there been any recent code audit?

この条件に照らせば Letter Sealing は最初の2つはクリアしたけど5，残りは「もっと頑張りましょう」な状態。 せめて条件4までは全て対応していただきたいところだ。

LINE の場合，アカウントの乗っ取りや成りすましが（手を変え品を変え）現在も続いているようなので，（脆弱なユーザの purge を含めて）そろそろ抜本的に対策していかないと「暗号化したけど意味ないじゃん」ってことになりかねないと思う6。

参考

  1. Ephemeral かどうかは通信が PFS (Perfect Forward Secrecy) を満たすか否かに関わってくる。 ↩︎

  2. 「HMACは、ハッシュ関数(hash funciton)という一方向性関数(one-way function)でメッセージに対するデジタル署名(digital signature)を取得し」と書かれているのは何かの冗談だと思う。英語の記事にはそんな記述ないし。 ↩︎

  3. ただし中間者攻撃は（昨年の OpenSSL に対する HeartBleed のように）既に攻撃が可能な状態なら相当な脅威だけど，攻撃を行うための前提条件を揃えるのは結構面倒なので，全体としてのリスクはそれほど高いわけではない。 ↩︎

  4. これ自体は妥当。もっと言うなら， ephemeral な鍵であればおそらくセッション毎に異なる。 ↩︎

  5. PFS を満たすなら条件4も満たす。 ↩︎

  6. ていうか， LINE はユーザを増やしすぎたよね。これは Facebook とかでも同じだけど。総じて LINE は真正性について甘い。むしろ意図的に避けてる印象。真正性を担保できない状態で，どれだけ暗号化に力を入れようとも無意味。 ↩︎