LINE「独自暗号化」のメリットと安全性について

LINEが使用している「独自の」暗号化手法について、情報が一部開示（参照：LINEの暗号化について « LINE Engineers' Blog）され、Twitterでもやりとりをしたので、まとめてみる。

■なぜTLSを使わないか

TLSではなく、１パスのメッセージ暗号化を使っている理由については、Adopting SPDY in LINE – Part 2: The Details « LINE Engineers' Blogに以下のような記載があり、TLSを使うことによるレイテンシの増加を懸念しているためと考えられる。

3G mobiles networks normally operate at slow speeds. （中略）If the connection changes modes when the user sends a message, we are forced to wait until we receive the server response before we can do anything else.

■どのような暗号化手法なのか

RSA暗号に加え、ブロックサイズが128bitの共通鍵暗号を用いており、共通鍵暗号の鍵をサーバのRSA公開鍵で暗号化し、共通鍵暗号で暗号化されたメッセージとともに送信していると考えられる（参考：ツイート 1, 2, 3, 4）。

おそらく、リクエストを送信する度に、大筋で以下のようなことを行っているのではないか。

# AES鍵を生成
AESKEY=`openssl rand -hex 16`注6

# 初期化ベクタを生成
IV=`openssl rand -hex 16`

# AES鍵をサーバの公開鍵で暗号化注1し、HTTPリクエストヘッダとして送信
echo -n "$AESKEY" | openssl rsautl -encrypt -pubin -inkey server-public.pem -in /dev/stdin | openssl base64

# POSTリクエストのボディをAESを利用して暗号化し、送信
echo -n "$content" | openssl enc -aes-128-cbc -in /dev/stdin -K "$AESKEY" -iv "$IV" | openssl base64

■この手法は安全か

RSAやAESといった暗号アルゴリズムは正しく使わないと脆弱になるし、どのように使っているかは今回開示されていない。とは言え、このように良く知られた部品（PKCS #1 v1.5とAES-CBC）を単純な形で組み合わせているのであれば、問題がある可能性は低い^注2。実際のところ、上記推測例は、秘話化という観点からは僕には特に問題がないように思える。問題があるなら誰か教えてほしい^注3。

手法の推測が正しいならば、「通信全体について、他国からアクセスすることは不可能」^注4ということだし、「システムに直接侵入するのではなく、通信回線とサーバーの間でワイヤタッピング」^注5することにより情報が漏洩している可能性は極めて小さいのではないか。

■同様の暗号化を行いたい場合はどうすればいいか

ウェブアプリケーションなどで使用が容易なメッセージ暗号化手法については、現在、JSON Web EncryptionがIETFで標準化の最終段階にあります。完全性保護も含まれているし、標準化団体での安全性検証が行われているこちらを使いましょう。対応しているライブラリについてはJSON Web Token (JWT) - OAuth.jpが参考になるかもしれません。

注1: この例ではPKCS #1 v1.5を使用しているが、RSA-KEMが、より望ましいかもしれない
注2: CBCモードの使用法については、NISTが出しているガイドライン（NIST SP 800-38A）と、CRYPTRECによる安全性評価を参照
注3: リプレイ攻撃への対策や完全性保護については、この例には含めていない
注4: 参照：LINE、改めて傍受を否定　「暗号化後データは独自形式、解読は不能」 - ITmedia ニュース
注5: 参照：韓国国情院がLINE傍受：FACTA online
注6: 生成している鍵とIVの長さが64bitになっていたのを修正 (11:21am)