LINEアプリ、エンドツーエンドの暗号化を実装 46
ストーリー by hylom
今まではメッセージを見られていた可能性があるということですよね 部門より
今まではメッセージを見られていた可能性があるということですよね 部門より
Printable is bad. 曰く、
LINEがメッセージングアプリ「LINE 5.3」で、メッセージをエンドツーエンドで暗号化する「Letter Sealing」機能を実装したことを発表した（公式ブログの発表）。これにより、悪意のある第三者だけでなく、LINEサーバの管理者でさえもメッセージの内容を復号することができなくなるという。
Letter Sealing機能は、メッセージをやり取りする個人間で楕円曲線DH方式（Elliptic Curve Diffie-Hellman）を用いて暗号化鍵を交換し、エンドツーエンド暗号化に用いる256bitの共通鍵を生成する。メッセージの暗号化には強度の高いAES-CBC-256が用いられている。また、改ざん防止にはハッシュ関数でメッセージに対するデジタル署名を取得し、署名値を再度暗号化して転送する方式であるHMACが使われている。なお、技術的な詳細は公式ブログで解説されている。
この機能がデフォルトで有効となっているのは現時点では一部のユーザーだけだが、LINEはこの機能を段階的に適用拡大していく考えのようだ。
その鍵はどうやって検証したの？ (スコア:2)
クライアント間で公開鍵をセキュアに受け渡しする必要があるわけですが、どうやって実装してるんですかね？
公開鍵の所有者確認をLINE側しかできないのであればメッセージだけ暗号化してもLINEが中間者になれるのは変わらないのですが。
LINEの中の人は 「なりすまし」 が可能 (スコア:4, 興味深い)
「公開鍵」を悪意のある第三者の公開鍵にすり替えるなりすまし攻撃を防ぐためには、信頼できる第三者機関（Trusted Third party）が各人のID（LINE の場合、LINE ID）と公開鍵を対応付けて認証する必要があります。
SSL/TLS の場合には VeriSign などの認証局（CA）がそれを行っているため、VeriSign の中の人であれば（通信を改竄できる状況ならば）なりすまし攻撃が可能です。同様に、LINE株式会社の中の人ならば、自分の公開鍵（悪意のあるLINE株式会社の中の人の公開鍵）を、会話相手の公開鍵だと認証することで、会話相手になりすますことが可能だと思われます。
認証局（LINEの場合、LINE株式会社）がなりすまし攻撃をすることは、技術的に防ぎようがないので、自分や会話相手の公開鍵のフィンガープリントを表示・確認できる機能を実装していただきたいものです。フィンガープリントの表示・確認機能があれば、安全な方法（リアルで会うなど）で相手の公開鍵のフィンガープリントを確認することで、なりすまし・中間者攻撃を完全に防ぐことができます。
（現状の Letter Sealing でも、LINE株式会社の中の人以外による、なりすまし攻撃・中間者攻撃は防ぐことができます）
Re:LINEの中の人は 「なりすまし」 が可能 (スコア:3)
信頼されている認証局が公的に発行するのとLINEがLINEのために発行するのでは大違いです。
公的なCAも不正な証明書を発行すればなりすましできますが、それは現実的ではありません。CAがまがりなりにも信頼されているのは不正が技術的に可能・不可能ではなく、不正を第三者が検証できると考えられていることと、不正によって信頼を失ってブラウザベンダやユーザに失効させられるリスクを背負っているからです。
LINEがLINEの発行したIDに対してLINEのクライアントアプリでのみ検証可能な公的でない証明を与えるのでは意味がありません。またLINE以外による盗聴を防ぐだけであればエンドツーエンド暗号化は不要です。
Re:LINEの中の人は 「なりすまし」 が可能 (スコア:1)
＞またLINE以外による盗聴を防ぐだけであればエンドツーエンド暗号化は不要です。
そうかな。LINE以外による盗聴を防ぐためにも、公開鍵暗号利用したエンドツーエンド暗号化が一番簡単で効果的な気がするけど。
LINEアプリのリバースエンジニアリングなども考慮すると、他の方式で簡単に盗聴を防げる気がしない。
Re:LINEの中の人は 「なりすまし」 が可能 (スコア:2)
問題なのは"簡単で効果的な"公開鍵の交換手段が無いことです。
まともな実装と信頼できる鍵交換手段さえあればリバースエンジニアリングで現代暗号の通信は盗聴できません。
Re: (スコア:0)
LINEアプリのリバースエンジニアリングなども考慮すると、他の方式で簡単に盗聴を防げる気がしない。
メッセージはすべてLINEのサーバ経由と思うので、それにTLS使えば良いだけでしょう。
つーか鍵交換までのサーバとの通信は暗号化する必要あって、どうせそれに使うんだろうからそれで必要十分って事になる。
メッセージがP2Pならしょうがないけど。
Re: (スコア:0)
事故れす
メッセージは一定期間ラインサーバに保管されてるんだったけなたしか。
それの流出時の対策には有効だねそういえば。
Re: (スコア:0)
え、他社を信用するなんてもってのほかでしょ? クラウドサービスで情報流出があるたびにみんなそう言ってるんだけど。
Re:LINEの中の人は 「なりすまし」 が可能 (スコア:2)
認証局（LINEの場合、LINE株式会社）がなりすまし攻撃をすることは、技術的に防ぎようがないので、自分や会話相手の公開鍵のフィンガープリントを表示・確認できる機能を実装していただきたいものです。
LINE側が信用できない状況で、LINEアプリが表示したフィンガープリントを信用するんですか？
確認する意味が無いので最初から使わないのがよいと思います。
Re:LINEの中の人は 「なりすまし」 が可能 (スコア:2)
ごもっとも。
おっしゃる通りでした。
Re:その鍵はどうやって検証したの？ (スコア:1)
NSAに管理委託すればいいんですよ
# こっそりより堂々と
Re: (スコア:0)
このあたり他のメッセージアプリはどう対応しているんでしょうね。
Re: (スコア:0)
>LINEサーバの管理者でさえ、メッセージの内容を解読（復号）することはできなくなりました。
というのは暗号化の仕組みをよく知らない人にとっては誤解されそうな記述ですよね
Re: (スコア:0)
>クライアント間で公開鍵をセキュアに受け渡しする必要があるわけですが、どうやって実装してるんですかね？
自分の公開鍵は、名刺に書いて、相手に直接渡すのが良いかと思います。
技術的な詳細を公開するのはよいことですが (スコア:0)
それをどうやったら検証できるんでしょうかね？
Re:技術的な詳細を公開するのはよいことですが (スコア:1)
児童ポルノで通報されそうな内容を送ればいいんじゃないですかねw
Re: (スコア:0)
韓国で検閲されそうなのは「ライダイハンをユネスコ記憶遺産に推薦！」ですかねー
Re: (スコア:0)
ライダイハンは日本ほとんど関係ないし、記録文書も持ってないでしょ
在日の記録として済州島虐殺を登録するほうが筋がいい
Re: (スコア:0)
androidエミュレーターなどにLINEをインストールして通信内容をキャプチャし調べればよいのでは。
Re: (スコア:0)
通信が暗号化されていることは確認できても、それがLINEサーバ側で復号
できないことを証明するのは、難しそうですが……。
でも、こんな機能を実装するということは、今後はビジネスでの利用を
推していくつもりなんですかね？
今まではサーバ側で閲覧可能で、韓国の司法から要請があればLINEのログを
提出することになるので、ビジネスでは使えない、というのが定説だった
ように思いますが。
Re:技術的な詳細を公開するのはよいことですが (スコア:2, 参考になる)
外部の人間が検証することは無理かな。
第三者の監査みたいな形でLINE社に受け入れてもらう以外。
プライバシー重視するのは大切なんで、ビジネス向けじゃなくても個人向けでも必須のセキュリティ機能だと思いますよ。
大手のメッセンジャーサービスの多く(Facebook、Skype、Hangoutなど)が対応してないですけどね。
ウェブインターフェイスが必要だと無理だもんなぁ。秘密鍵をWebStorageか何かローカル側でセキュアに保存できればいいのかもしれないけど、まぁリスキーだな。
Re: (スコア:0)
とりあえずLINE側に暗号鍵が転送されていないことを確認できればいいんじゃないかな。
Re: (スコア:0)
暗号鍵が暗号化されてたらどうやって確認するの？
Re: (スコア:0)
相手に送信された公開鍵がすり替えられていないことも確認しないとだめです
そのブログの記事正しいの？ (スコア:0)
こういうツイートをみかけましたが。
https://twitter.com/bulkneets/status/653849397864755200 [twitter.com]
> http://developers.linecorp.com/blog/ja/?p=3591 [linecorp.com]
> この記事は自分が出した修正指示が適切に反映されないまま公開されました。
> シェアしないでください
この後、修正されたという話も見かけてないので、まだ間違ってるのでは？
Re: (スコア:0)
続報:
https://twitter.com/bulkneets/status/654947084655681536 [twitter.com]
> @bulkneets まだツッコミたい箇所はありますが、概ね修正されました。
とのことです。
Re: (スコア:0)
>まだツッコミたい箇所はありますが、概ね修正されました。
https://twitter.com/bulkneets/status/654947084655681536 [twitter.com]
暗号化とかやめた方がいい (スコア:0)
犯罪に使われたりその温床になっているんだから、通信記録全部ロギングしておいて
警察から要請があったらその通信内容全部提出できるくらいでいいよ。
Re: (スコア:0)
そんなの通信の秘密に抵触するだろ
Re:暗号化とかやめた方がいい (スコア:1)
一応、日本には通信傍受法(盗聴法とかって騒がれてたヤツ)ってのがありますけど…。
https://ja.wikipedia.org/wiki/%E7%8A%AF%E7%BD%AA%E6%8D%9C%E6%9F%BB%E3%... [wikipedia.org]
ただし今回みたいな暗号化された通信には対応できなそうですが…。
Re: (スコア:0)
令状があればできますけどね。
Re: (スコア:0)
令状があったところで、会社側は復号できないんだから、どうしようもないと思うが。
暗号文を渡すくらいか。「うちじゃこれが限界です」と言い訳できるかどうか。「ユーザーの秘密鍵盗み出せや」なんて命令もできるんだろうか。
でも、これ言いだすと、Googleなんかに「TLSの鍵出せや。中継点で盗聴するけぇ」が通ってしまう。
まぁ本文は無理としても、メタデータはわかるだろうし、ユーザー特定して、個人向けの令状にすればいいのかな。
つっても、サーバーには暗号文しかないんだし、問題あるのかさえわからんはずだがな。
Re: (スコア:0)
>「ユーザーの秘密鍵盗み出せや」なんて命令もできるんだろうか。
なんてことをしなくても公開鍵の交換を横取りずれば盗聴は可能です。LINEサーバーにはそれができます。
Re: (スコア:0)
公開鍵暗号を使っているようなので、送信側クライアント及び受信側クライアントの秘密鍵はサーバに報告する必要がありません。
必要ないけどこっそり報告してる可能性はありますが、清く正しく実装されていればサーバーも盗聴は出来ません。
公開鍵の交換の段階から二者の公開鍵を両方共偽の鍵に差し替えて中間者攻撃されなければ問題ない、はずです。
Re: (スコア:0)
韓国には日本の「通信の秘密」に該当する権利は存在しないだろ。
Re: (スコア:0)
この国では法律なんてものは警察と国が好きなように解釈するものです
日本をまともな法治国家と思っていたらそれは勘違いです
少なくともこの国には法の番人はいません
おお。すごいじゃん。 (スコア:0)
韓国に日本の地域レベルの情報が筒抜けになる、とは言えなくなったな。
あとは権限だな。
使用する必要の無い権限を削除してもらえれば、
何かの際に一定範囲の端末を誤作動させたり使用不能にさせられるという懸念が無くなる。
メッセージングアプリの流行は3年周期らしいが、ビジネスで確かな成功を手にするために、
まともな社会人が選べるサービスへの転換を頑張っていただきたい。
Re: (スコア:0)
何か色々誤解している気がします。
Re: (スコア:0)
iOSだと個別に権限設定できるし、Androidも6で個別設定できるようになるよ。
アプリ側が対応すれば、だけど。
Re: (スコア:0)
破壊的動作を疑うほど信用出来ないアプリって前提なのにそのアプリがの自己申告した
「エンドツーエンドで暗号化している」って主張が信じられると根拠が全くわからない。
Re: (スコア:0)
> openssl使えば一日とかからず実装できるようなことをようやくやってドヤ顔か。
「LINEサーバの管理者でさえもメッセージの内容を復号することができなくなる」
をopensslで実装すると？
Re:実はど素人実装 (スコア:1)
きっと、送受信者間にVPNを張って、その上をSSLで通信するんですよ。(「VPN張る方がよっぽど大穴になりそうだ」とか「VPNを暗号化しとけば、SSLは要らない」といった点は気にしない)
…閑話休題
opensslはともかく、「できるだけ既存の実装を流用する」という元コメの意見自体は妥当だと思うのですが、今回のようなものの場合どういう実装が考えられますかね。
ぱっと思い浮かぶのはGnuPGですけど、GPLだからライセンス的に採用は無理だし…ちょっと美味い(最小限の手間で実装できる)方法が思いつきません。
Re: (スコア:0)
iOS9とかElCapitanとかのApp Transport Securityで必須の
Forward secrecyならセッションの安全性が保たれる
→それを実現するやり方の1つが楕円曲線DH方式を用いた
暗号化鍵交換だ
という落ちでは？
だとすると鍵を作る側のopensslは関係無く、鍵を検証する
側の実装が必要で、App Transport Securityとかがそれ
では？
Re: (スコア:0)
opensslで脆弱性が明らかになったケースとか考えると、全部入り暗号スイート使うのと
「既存の暗号アルゴリズム」を独自実装するのではどっちが安全かは甲乙つけがたいと思う。
ぐちゃぐちゃなデータを受け入れる暗号関係の関数は異常系ってのがそもそも少ないというか、
そういうバグがあれば既存のプログラムが吐いた暗号文と互換がない等で直ぐに発覚するだろう。
メタなデータや拡張は扱わないからそのへんでの脆弱性も心配ないし。
暗号アルゴリズムの組み合わせによる暗号アルゴリズムの安全性やその使い方は問題だけど、
それは全部入り暗号スイートでもやらかすときはやらかしちゃうしなぁ…
暗号アルゴリズムそれ自体を自作は破綻してる可能性が非常に高いから辞めたほうがいいけど。
「10秒後には使い物にならなくなった暗号 [h2np.net]」みたいになるのは目に見えてる。