  |
はてなキーワード: aesとは
Akira Ransomwareは、近年特に注目されているランサムウェアの一つで、その動作は高度で多様な手法を取り入れています。以下に、Akiraランサムウェアの動作について詳しく説明します。
侵入経路
Akiraは主にフィッシングメール、リモートデスクトッププロトコル（RDP）の悪用、既知の脆弱性の悪用などを通じてシステムに侵入します。特に、未修正のソフトウェアやシステムの脆弱性を狙うことが多いです。
初期感染と展開
システムに侵入すると、Akiraはネットワーク内で横移動を試みます。これは、ネットワーク内の他のデバイスにも感染を広げるためです。横移動には、認証情報の窃取や利用可能なネットワーク共有の探索が含まれます。
ファイル暗号化の前に、Akiraはターゲットシステムの特定のディレクトリをスキャンし、暗号化対象のファイルをリストアップします。次に、強力な暗号化アルゴリズム（通常はAESとRSAの組み合わせ）を使用して、ファイルを暗号化します。
最近のバージョンでは、部分的な暗号化手法（インターミッテント暗号化）を採用することで、暗号化速度を上げつつ、検出を回避する手法が確認されています (Bitdefender)。
データの窃取
暗号化に加えて、Akiraは重要なデータを盗み出し、そのデータを公開することで二重に脅迫することがあります。これにより、被害者に対する身代金要求の圧力を強化します。
暗号化が完了すると、被害者のデスクトップに身代金要求メッセージが表示されます。このメッセージには、データを復号化するための手順と支払い方法が記載されています。通常、暗号通貨（ビットコインなど）での支払いが求められます。
特徴的な技術
RustとC++の利用
Akiraの一部バージョンはRustというプログラミング言語で書かれており、これによりコードの安全性が向上し、セキュリティ研究者による逆コンパイルが難しくなっています。また、C++で書かれたバージョンも存在し、多様な環境での実行が可能です (CISA)。
VMware ESXiの標的化
Akiraは特にVMware ESXi仮想マシンを標的とすることが多く、これにより企業の仮想環境全体に影響を与えることができます。
Akiraは単純なファイル暗号化にとどまらず、データ窃取やネットワーク内での横移動、他のマルウェアの導入など、多層的な攻撃手法を組み合わせています。これにより、攻撃の成功率を高め、被害者に対するプレッシャーを強化します。
ITエンジニアの業界では資格をとってもなんの意味もないとよく言われる。
あるITエンジニア(インフラ〜バックエンド系)おじさんもその原理主義者のような人でIT系の資格取得をバカにしていた。そんな暇があったら個人開発の一つでもすればいい。資格を持ってるなんてむしろバカをアピールすることだという言いようだった。
しかしある時、おじさんと会話しているとSSO（シングルサインオン）を知らなかった。またある時は、AESが共通鍵暗号の規格だということを知らなかった。どれもAPやベンダー資格の勉強をしてればよく目にするもののはずだ。
Pマーク(or ISMS)が批判されているが、皆どんなチェックがされるのか知ってるの？ 内容を知らないのでイマイチ批判の波に乗れないんだよね。自分の検索能力が低いだけかも知れないけど、公開されていないようで文書が見つからず真偽を確かめられないし。
なので、ここから先は自分の推測。間違っていたら指摘して欲しい。
PマークやISMSの認定では「パスワード付きzipしろ」と明言されているわけではなく、「メールでファイルを送るなら暗号化しなさい」くらいの話だと想像している。
もちろん、「パスワード付きzipで送付します！」に対してダメと言わないPマークが悪いとも言えるが、以下が担保されればセキュリティとしては問題ないように思う。
審査がザルなんだろうとは思うけど、受ける側が嘘ついてたらどうしようもないし、PPAPが手間が掛かる/非効率である点はPマーク側がどうこう言う話ではない（本当はコストを考慮した上でのセキュリティであって欲しいけどね）。
あと、別ソリューションとしてよく挙げられる外部ストレージサービスの活用について、Pマーク側が禁止しているわけじゃないよね？ 禁止していないなら、それを採用しないお宅が悪いのであってPマークを批判するのはお門違いなのでは？と思っている。
とりとめもなく書いたが、思っていたことをぶち撒けられてスッキリした。
じゃあな。
http://www.med.oita-u.ac.jp/infectnet/SARS/SARS_report_00567.html
効果が確認されているのは、食器、野菜洗浄用の製品で、成分として直鎖アルキルベンゼンスルホン酸ナトリウム、またはアルキルエーテル硫酸エステルナトリウムを16％以上含むものだという。
従来のエチルアルコールに加え、台所洗剤の使用を推奨しているのは、臨床的にSARSが疑われるか、あるいはSARSであることが確認された患者が発生した場合に患者の部屋などに対して行う消毒処置。台所用の合成洗剤を１lのぬるま湯に対して５〜10ml以上加えて用いる。使用するときには、手袋、手術用以上の性能のマスク、ゴーグル、ガウンなどを着用し、窓を開け放って可能な限り日光が届くようにする。その上で、消毒剤が十分長時間残留するように、清拭することを勧めている。消毒剤を噴霧するとウイルスなどを空気中に舞い上がらせる危険性があるため、拭き取りに限る。体液などが付着した部分には、ティッシュペーパーなどに消毒剤を染み込ませ、５分間以上経過してからから拭きする。
https://medical.nikkeibp.co.jp/inc/all/hotnews/archives/279202.html
と呼ばれる。
SARAYA ヤシノミ洗剤
辺りが当該商品に相当するので、消毒液が買えなかった人はどうぞ。
なんで作る仕組みがないんだよ。
zlibやCommonCryptoはswift用のライブラリがないので、裏技的やり方でObjective-Cのライブラリを引っ張ってこないといけない。
zlibは何をどうやってもgzipしか作れないし、作ったgzipをCommonCryptoのAESで暗号化したら、今度はどうやっても解凍できないし。
あとzlibによる圧縮で、圧縮前の拡張子を覚えさせる手段が見つからなかったので、ファイル名に圧縮前の拡張子を含めさせておかないと、解凍後に手動で拡張子を追加しないといけない。
そりゃ、APIのドキュメントをくまなく読み込めば全て解決するんだろうけど、そんなコストは掛けられない。
だからなのか、ググってみると9割方SSZipArchive使えって記事が引っかかる。
あのさ、そういう目的特化で作られているんだから、使えば一瞬で目的達成できるのは分かるよ？
そこじゃないんだ。そしたらプラグインみたく必要なライブラリを入れまくって解決した気になるのは違うと思うし、それが無理なケースもあるんだよ。
そもそもの疑問として、タイトルに有る通り「暗号化zipを作りたいだけなのに」なんで最初から仕組みが用意されてないんだ。
{ 'transaction':[ 'key':'some_token_like_SHA-2', 'descriiption': 'bar', 'from_wallet': 1234567890, 'to_wallet': 0987654321, 'total_amount': 9999999999999, 'tax_amount': 999999999999, 'timestamp': yyyymmddhhmmss ] }
http://www.alexkyte.me/2016/10/how-textsecure-protocol-signal-whatsapp.html これエキサイト翻訳か？主語が全部theyという支離滅裂な英語なんだが。
----
TextSecureの目標は「経路末端までのセキュリティ、否認性、前方秘匿性、将来の秘匿性のすべて」を提供することである。具体的には、可能な限り短い時間だけ鍵情報を保持するメッセージストリームを二者の間に構築するということを目指す。将来に鍵の危殆化があっても、現在観測されたトラフィックを復号化できなくするのだ。
以下にSignal Protocolの批評的分析を羅列してある。実装の構造を研究し、発見した欠陥を記述し、上述の目標がどれほど実現されているかを評価するものである。まず仕組みの説明をしてから、より詳細な分析を続けることにする。
TextSecureは、今ではSignalと呼ばれているアプリに与えられた名の一つだ。コードも文書も一貫してTextSecureという名を使っている。一貫性を保つため、システム全体をTextSecureと呼ぶことにする。
TextSecureは、非同期整合性に焦点を当ててOff-The-Recordというチャットプロトコルを改造したものだ。OTRが対話的ハンドシェイクを必要とする一方、TextSecureは不確定な遅延を認めない。メッセージを送れるようになるまでアプリを表示したままにしてハンドシェイクを遂行しなければならないというのであれば、ユーザ体験はひどいことになる。
そうではなく、通常の鍵交換においてサーバが果たす役割の部分だけ、将来のクライアントが取得しに来るよう中央サーバに格納される。このサーバは、すべてを復号化できる鍵情報は預けておかない、信用なし経路となる。すべての暗号化は末端どうしだ。
TextSecureは暗号学の基礎のほんの一部を使うものである。公開鍵暗号は楕円Diffie-Hellmanを通し、Curve25519を用いて実行される。AESがパディングなしカウンター(CTR)モードとサイファーブロックチェーン(CBC)モードの双方で対称暗号に使われる。HMAC-SHA256がメッセージ認証に使われる。これらが信頼の基礎(TCB)である。
TextSecureの暗号化エンジンの中心部はAxolotlダブルラチェット・アルゴリズムである。大まかに言うと、一方向にだけ回ることのできるラチェットが二つあり、一つは受信ラチェット、もう一つは送信ラチェットである。この構造により、鍵交換の前半を保管しておいて、後から非同期的に再生し完全なハンドシェイクを得ることが可能になっている。
受信ラチェットはメッセージが受信されるときに使われるが、そこには次の鍵交換のための新しい材料が含まれていなければならない。この材料が後ほど暗号化やメッセージ認証に使う対称鍵の生成に用いられる。
送信ハッシュラチェットは前回の整合性ある共有秘密から生成された鍵ストリームを使って新たな鍵セットを生成する。このラチェットは、受信ラチェットが進んで共有秘密が変化するとリセットされる。
ここで注目すべきは、メッセージを送信するために送信者が待つ必要は一切ないということだ。いつでも送信の第一歩を踏み出すことができ、その一歩は必ず有限の時間で終わる。メッセージはすべて異なる対称鍵で暗号化されるが、これにより、ある時点の鍵は、どちら側のデバイス上のものであっても、過去に送信されたメッセージを復号化するためには使えないことになる。(ただし後で一つ警告がある。)
登録は、クライアントに言って、連絡用の電話番号をサーバに教えてもらうことから始まる。また同時に、トークンを通話とSMSどちらで受け取りたいかの希望も登録してもらう。このトークンが持ち主の証明となり、TextSecureで情報を登録できるようにしてくれる。
クライアントはメッセージ認証と暗号化の対称鍵('signaling'鍵)、および長期公開鍵を送る。
また、複数のプレ鍵も送信する。これはクライアントが受信者になる時の鍵交換の半分、クライアント側部分の使い捨てコピーである。こうして保管されているプレ鍵のおかげで、将来の送信者はクライアントの応答を待つ必要もなく鍵交換を完了でき、こうして遅延を劇的に減らすことができる。クライアントは「最後の手段のプレ鍵」もアップロードするが、これは最後に使われ、受信者が新しいプレ鍵を追加するまでのセッションでずっと共有され続ける。
他のクライアントからも使われるプレ鍵に頼ることについてSignalが警告をしないというのは、筆者の意見では、理想と程遠い。
クライアントは次にGoogle Cloud Messagingに登録して、登録IDをTextSecureに出す。このTextSecureへの登録には、クライアントがSMSを受け取りたいかデータだけにしたいかの情報も含まれる。
TextSecureはクライアントどうしがお互いの長期鍵のフィンガープリントを比較して本人確認できるようになっている。鍵をQRコードとして表示して便利に検証できるようにする機能も含まれている。
送信者は、まず相手のプレ鍵を要求し、プレ鍵インデックス、プレ鍵、登録ID、長期公開鍵をもらう。これらを使い、HKDFという鍵派生アルゴリズムを通して共有秘密を取り決める。この秘密情報をルート鍵と呼ぶ。
このメッセージだけの一時鍵ペアが生成される。ルート鍵を使ってHKDFで新しいルート鍵とつなぎ鍵を派生させる。このつなぎ鍵は、暗号化とMACの鍵を生成するのに使われる。
最後にAESカウンターが初期化される。カウンターは二つある: ctrとpctrだ。ctrカウンターはメッセージ送信ごとに増える一方で、pctrカウンターは、最後の既読メッセージの番号を保持する。これにより、受信者側にバラバラの順番で届いたメッセージを正しく並べ直すことができる。
これらを使って相手にメッセージを暗号化し、それをSignalサーバに送る。このメッセージには、相手が鍵交換ハンドシェイクを完了できるだけの必要情報が含められている。
SignalサーバはGoogle Cloud Messenger登録IDが件の電話番号に合っているかチェックし、メッセージを'signaling'鍵で暗号化してからクラウドサーバに送る。この遠回しな方法により、Google Cloud Messengerがメッセージの送信元を知らずにいることが保障される。
受信者はプレ鍵インデックスを受け取り、送信者がどのプレ鍵を使ったかをそれで調べる。そして送られてきた情報を使ってハンドシェイクを完了したり送信者と同じルート鍵を持ったりする。送られてきたメッセージを復号化するために使う鍵は、このルート鍵が生成する。
相手が返信する前に、もとの送信者から続きのメッセージを送りたい場合は、新しいつなぎ鍵を生成して、これを使って新しい暗号化およびメッセージ認証の鍵を得る。
受信者が返事を出したい時は、まず新しい一時鍵ペアを選ぶ。送信者の一時公開鍵と自分の一時秘密鍵を使って、新しい共有秘密を生成する。これを使って新しいつなぎ鍵を得て、そこから新しい暗号化と認証の鍵を得る。これを使ってメッセージを暗号化し、さきほどの新しい一時公開鍵と一緒に送信する。
TextSecureは、サーバとクライアント間の共有秘密、いわば機械生成パスワードを使って、新しいプレ鍵のアップロードを認証する。これは送信メッセージの認証にも使われる。このパスワードを漏らしてしまうと、それだけでメッセージの送信も鍵アップもそのユーザになりすましてできてしまうことになる。エキスポート機能があった頃はTextSecureクライアントを別のスマホに移行することができたが、この機能は削除された。エキスポート情報には機械生成パスワードが含まれていたからだ。この平文バックアップはデバイスのSDカードに置かれていたので、他のアプリから読むことができたのだ。
この機能はそれ以来削除されたままだ。なくて困る人がいるとしても、これはユーザビリティの問題ではなく、現実の問題であり、それに対する後ろ向きな対策なのである。
この攻撃は偽配送の一種だ。攻撃者がUKS攻撃を実行すると、ある送信者が攻撃者に向けて送ったつもりのメッセージが、攻撃者から別の人(標的)へのメッセージとして送信される。
これは能力のある攻撃者にとっては簡単にできる。TextSecureサーバ上にある自分の公開鍵を、標的の公開鍵に変えればいい。これは自分の電話番号を再登録すればできる。送信者はQRコードを使って、相手のフィンガープリントが合っていることを検証できるが、これが本当に標的の鍵のフィンガープリントになるのである。
それから、今度は送信者のアカウントを再登録して、その検証SMSか確認通話が送信者に到達しないよう横取りしなければならない。これは太っ腹に権限を与えられた人には造作もないことだ。こうして、送信者として認証し、既知の署名つきメッセージを送信できるようになる。
この攻撃はTextSecureでは解決されていない。プレ鍵の署名は追加したが、まだ暗号学的にIDと関連付けられているわけではないので、奪われて再生される危険がある。
できることがあるとすれば、送信者と受信者の双方がメッセージの暗号化された本文内で言及されるようにすることなどだ。
TextSecureはその構造のおかげで前方秘匿性を獲得している。前方秘匿性(forward secrecy)は、もし長期公開鍵が安全なままであれば、ある時点の対称鍵が漏れても、そのセキュリティ突破は限定的な時間範囲にしか有効でないとする。新しいラチェットのそれぞれに公開鍵が必要であることから、これは達成されている。
完全前方秘匿性(perfect forward secrecy)は、クライアントの持つある時点の鍵が奪取されても、それ以前に送信したメッセージの復号化が不可能である性質と定義されている。このことはTextSecureのwire protocolにより施行されるが、少々ことば遊びに入ってくる。というのも鍵はデバイス上にのみ格納されているので、アプリ上の他の鍵にアクセスすることなく鍵が暴露されることはありそうにない。長期鍵だけではメッセージを復号化できず、ラチェットのステートに対応する一時鍵が必要になるが、これはそのスマホから引き出すことができるので、送信したものの返信されていない(前回のラチェットを使用した)メッセージを復号化できる。これは技術的に言えば「以前の」メッセージの暴露である。
否認性(アリバイ)はさらにあやふやだ。ある特定のメッセージについて、それはだれにでも作成できたのだと言うことは可能だが、その一方で、プレ鍵は公開されているので、TextSecureの中央集中構造が脅威をもたらす。TextSecureサーバは認証とメッセージ転送をするものだが、それを記録することもできる。内容は末端どうしで暗号化されているとはいえ、メタデータは違う。
Analysis Whitepaper:
http://ieeexplore.ieee.org/document/7467371/
Marlinspike, Moxie (30 March 2016). "Signal on the outside, Signal on the inside". Open Whisper Systems. Retrieved 31 March 2016. https://whispersystems.org/blog/signal-inside-and-out/
原文：https://community.spiceworks.com/how_to/125475-teslacrypt-2-2-0-removal-and-decryption
原題：TeslaCrypt 2.2.0 Removal and Decryption
原著者：Isaac Rush's (hewhowearsascarf) Portfolio of IT Projects - Spiceworks 氏 (Thank you for your contribution! This article is a translation of your post.)
私たちのワークステーションのうちの一つがTeslacryptランサムウェアに感染しました。すべての文書が暗号化され、拡張子はvvvに変えられました。マルウェア感染のにおいて最も安全な回復方法はコンピューターをワイプしてバックアップから復元させることです。しかし、それは場合によっては選択肢にならないことがあります。私たちの場合、ユーザはローカルコンピュータに何のバックアップもとっていませんでした。それで、私たちはランサムウェアを取り除く方法とファイルを復号する方法を確認する必要がありました。復号を達成させてくれたPythonスクリプトの作者であるGoogulatorに大きな感謝を送ります。https://github.com/Googulator/TeslaCrack
そこに書いてある説明に従うといいです。引用していくつか説明を付けたものを以下に用意しました。元の記事にはたくさんの指示が書いてありますが、私たちが行った手順は以下の通りです。
セーフモードで再起動し、Malwarebytes scanを走らせて、見つかったすべてのマルウェアを削除します。私は複数の信頼できるマルウェアクリーナーを使ってこれが消えたか確認することをお勧めします。必要だと言われたら再起動します。これでウィルスはきれいになったはずです。次はドキュメントを復号します。
私たちはPythonスクリプトを使って、AES公開鍵を特定して、その数値を因数分解して、それから秘密鍵を特定して、そしてファイルを一つ復号します。一度復号に成功したら、コンピュータすべてを対象に実行できます。できるなら、多く速く処理するために他のコンピューターを使ってください。
インストールは管理者権限で行ってください。また、インストール中の操作で、Pythonをパスに追加するオプションを必ず選択すること。
python -c "import urllib2; print urllib2.urlopen('https://bootstrap.pypa.io/ez_setup.py').read()"; | python easy_install pip
pip install http://www.voidspace.org.uk/python/pycrypto-2.6.1/pycrypto-2.6.1-cp27-none-win_amd64.whl
pip install ecdsa
私の実行結果は以下の通りです:
Cannot decrypt ./VENDOR LISTING BY CATAGORY.xlsx.vvv, unknown key
Software has encountered the following unknown AES keys, please crack them first using msieve: A1373BCF4EDB39BCFEDD44FA86A82498410A7E83456D8E80E52966F6717CB8B8E5846BBC7A540647AE770FEDEAA0E7F8A0466082156DB332A757407A12C9FB0 found in ./VENDOR LISTING BY CATAGORY.xlsx.vvv
Alternatively, you can crack the following Bitcoin key(s) using msieve, and use them with TeslaDecoder: 5ECA19D475A313AC3DEF915CE6FA37BE012CD1676590C8F253135A3AD92345B78C32C46DB3246ED84A7B9A8C62F1A13D2AF08F09FFB3551701E7B75CCC79457C found in ./VENDOR LISTING BY CATAGORY.xlsx.vvv
私の場合は以下の値をコピーしました。 A1373BCF4EDB39BCFEDD484FA86A82498410A7E83456D8E80E52966F6717CB8B8E5846BBC7A540647AE770FEDEAA0E7F8A0466082156DB332A757407A12C9FB0
さっきの数値はこのようになります: 8443554284208758706290725803426642738777516291375882082881197977752270634322152168104703798454983966849000112082164921264407639940139993317228747401502640
私の場合だと、8443554284208758706290725803426642738777516291375882082881197977752270634322152168104703798454983966849000112082164921264407639940139993317228747401502640 を入力して「Factorize!」を押してみました。もしあなたがラッキーなら、画面の左端には「FF」と表示されるでしょう。これは完全に因数分解されていて、すべての因数がリストされていることを意味します。この場合、あなたは以下のyafuを使う手順を行う必要はありません。unfactor.pyのところ(訳者注：手順19)までスキップできます。
もし「CF」や「C」と表示された場合、私たちはまず因数分解をするためにyafuを実行する必要があります。因数分解ができたら、 factordb.com に戻ってその整数を下のほうにあるレポートフィールドからレポートしましょう。そうすることで、その数値が「FF」で表示されるようになります。因数分解は数値の複雑さによって数時間・数日間・数週間かかります。因数分解が終わったら、私たちは秘密鍵を得るのに使用するたくさんの数値(因数)を得ていることでしょう。私はmsieve, yafuとこれらのバリエーションを試しました。これを動かすのは結構大変でした。いくつかの問題は説明が不完全で、すべての構文を与えられていませんでした。しかし、ついに私はyafuを動かしました。私が何をしたか、以下に書きます。
例: yafu-x64.exe "factor(8443554284208758706290725803426642738777516291375882082881197977752270634322152168104703798454983966849000112082164921264407639940139993317228747401502640)" –v –threads 4
因数分解を始めると、小さな因数は素早く見つかり、このようにリストされるでしょう : 「div: found prime factor = x」。ログファイルの中から「found prime factor」を検索します。
さらに「prp」も検索します。このような行が見つかるでしょう。: prp32 = 25647545727466257054833379561743
これが私の実行結果です:
unfactor-ecdsa.py VENDOR.xlsx.vvv 2 2 2 2 3 5 367 12757 25647545727466257054833379561743 75938537910569673895890812481364802067167 3858259146292441335085163995598583072203543699186432807503634945432314399
Found AES private key: b'\xbd\xa2\x54\x3a\x21\x75\xb9\xf3\x0d\xf6\xf3\x09\x60\xec\x08\x2f\x3e\xc5\xef\x61\xd4\x03\xa3\x5b\xc1\x47\x7e\x10\x47\x0a\x7c\x88' (BDA2543A2175B9F30DF6F30960EC082F3EC5EF61D403A35BC1477E10470A7C88)
'A1373BCF4EDB39BCFEDD484FA86A82498410A7E83456D8E80E52966F6717CB8B8E5846BBC7A540647AE770FEDEAA0E7F8A0466082156DB332A757407A12C9FB0': b'\xbd\xa2\x54\x3a\x21\x75\xb9\xf3\x0d\xf6\xf3\x09\x60\xec\x08\x2f\x3e\xc5\xef\x61\xd4\x03\xa3\x5b\xc1\x47\x7e\x10\x47\x0a\x7c\x88',
ファイルが復号されるはずです。
あなたの重要なファイルをバックアップしましょう！できればすべてのシステムで。同じようなことが起こった場合でも、回復するために無数の時間を使うかわりに、バックアップから復元できるようになるから。
きっとこれらの追加の手順は皆さんを助けます。自分がこの手順を行ったときはたくさんの問題がありました。それでもしあなたがこれを不完全だと思うなら、手順を更新するのでお知らせください。たぶん私たちはいっしょにこの手順をより完璧にすることができます。ありがとう！
https://community.norton.com/en/forums/how-decrypt-teslacrypt-vvv-files
http://www.mobilefish.com/services/big_number/big_number.php
http://gilchrist.ca/jeff/factoring/nfs_beginners_guide.html
http://www.mersenneforum.org/showthread.php?t=20779
http://developers.linecorp.com/blog/ja/?p=3591
Letter Sealing って何でしょうか。私気になります。
必要な範囲で、原文を引用しています。原文は先に引用元のアドレスと閲覧日時を記し、引用記法によって地の文と識別できるようにしています。
ECDHとAES256-CBC 使ってみた。通信相手の認証については読み取れない。
図2 において、 Server のところで Re-Encryption (一度復号されて、再度暗号化されている) ことが明示されています。
この図を素直に読むと、送信者からサーバーまでの通信路は暗号化されているものの LINE のサーバーが受信したところで復号されて平文で保存され、サーバーから受信者までの通信路は暗号化されていると理解できます。文脈から、この流れを変えたいのであると推測できます。
http://developers.linecorp.com/blog/ja/?p=3591 より引用、2015年10月14日 22時40分に閲覧：
加えて、LINEでは、仮に通信ネットワークの傍受が行われたとしてもメッセージを覗くことができないように、公開鍵暗号(public key encryption)方式を使っています。ユーザーに対してLINEアプリを提供する際、暗号化ができる公開鍵のみをアプリに入れて提供し、ユーザー端末とサーバが接続されたときだけLINEサーバでのみ解析できる暗号化された安全なチャネルを作ります。こうすることで、SSL(Secure Socket Layer)より軽く、LINEの全バージョンで使用できる安全な暗号化を実現できます。
SSL はすでに時代遅れの代物で、 2015年秋現在は皆さん TLS を利用されていることでしょう。 Web ブラウザで SSL 2.0 や SSL 3.0 を有効にしているそこのあなた、今すぐ無効にしましょう。
TLS では、公開鍵暗号方式や共通鍵暗号方式、電子証明書、暗号学的ハッシュ関数といった複数の暗号技術要素を組み合わせて安全な通信路を確保しています。
RSA に代表される公開鍵暗号方式は一般的に AES に代表される共通鍵暗号方式と比べて計算量が大きい、つまり重たい処理となります。
このため TLS では、通信路を流れるデータの暗号化に共通鍵暗号を用いて、共通鍵の共有や相手の認証のために公開鍵暗号方式を用いるのが一般的です。
仮にメッセージの暗号化に RSA を用いているとしたら、 SSL より軽いという点をどのように実装しているのか気になります。
http://developers.linecorp.com/blog/ja/?p=3591 より引用、2015年10月14日 22時40分に閲覧：
ユーザー側のLINEアプリ(クライアント)には、サーバが発行したRSA鍵を使用してデータの暗号化に使う暗号化鍵値を共有します。この鍵を利用してデータを暗号化すると、第三者はメッセージを見ることができなくなります。
これは上で説明したとおり SSL や TLS でも行っていることです。
RSA を用いているので安全であるという主張をしていますが、メッセージの暗号化に用いられている暗号スイート（アルゴリズムの種類、鍵の長さ、ブロック暗号の場合は暗号利用モード、そしてハッシュアルゴリズムの種類）は、その通信路が安全であると判断できるか否かを決める大切な情報です。
http://developers.linecorp.com/blog/ja/?p=3591 より引用、2015年10月14日 22時40分に閲覧：
既存のRSA方式も秘密データの共有に使う安全な方式ではありますが、鍵管理の面から見ると、ユーザー側の端末でそれぞれのRSA鍵をすべて管理しなければならないという問題があり、その代替手段としてDHを使用するようになりました。
DH および ECDH による共通鍵暗号に用いる鍵の交換は SSL や TLS でも実装されており近年では広く使われています。 SSL より軽いと主張し、 SSL や TLS が公開鍵暗号方式以外の要素によって担保している安全性をどのように確保しているか不明な実装に比べると、大きな改善です。
なお SSL や TLS においては通信相手の公開鍵を全て管理する必要がないように、上で説明した電子証明書による公開鍵基盤 (PKI) の仕組みを利用しています。
つまり共通鍵暗号に用いる鍵の交換にどのような手段を用いるかは、鍵管理とは（ほぼ）独立です。
http://developers.linecorp.com/blog/ja/?p=3591 より引用、2015年10月14日 22時40分に閲覧：
ここでメッセージの暗号化に使用している暗号化アルゴリズムはAES-CBC-256という方式で、現在一般に使われている暗号化アルゴリズムの中で最も強度が高いと評価されています。
メッセージ認証と組み合わせない CBC はビット反転攻撃に弱いことが知られています。 GCM ではデータの暗号化と認証を同時に行うためビット反転攻撃に耐性があります。 AESを GCM で利用するのは、 最近の TLS の実装では広く用いられており、 Google や twitter も利用しています。
CBC も CBC-MAC のようにメッセージ認証と組み合わせることでビット反転攻撃に強くなります。
図6 のとおり、 ECDH で共通鍵暗号に用いる鍵の交換を行うにしても通信相手の公開鍵は必要です。 上で説明したとおり鍵管理という問題への解決策になりません。また公開鍵が本当に通信相手のものであることをどのように検証するのかについても不明です。通信相手の検証は、送信側では秘密の話を他の人に知られないように、受信側では他の人になりすまされないように、双方にて必要です。
ここからは安易なパターンの想像ですが、通信相手の公開鍵情報は LINE ユーザー情報の一部として LINE サーバーで管理されており、必要に応じて安全な通信路を用いて LINE サーバーから取得するようなものではないかと思います。公開鍵情報のやりとりに用いられる通信路に正しく実装された TLS が用いられていて、サーバーとクライアントの両方が認証されていて、現在の水準から見て妥当なレベルの暗号スイートが用いられていることを願うばかりです。
公開鍵と秘密鍵がどこでどのように保管されているのか気になります。各端末で保管するのが安全ですが、サービスの要求として端末を乗り換えてもメッセージが読めるという条件を安易に満たすために秘密鍵を LINE サーバーに預託していないことを祈るばかりです。
ECDH 鍵の生成は計算量が大きい処理であり質の良い乱数を必要とします。 PC に比べると非力なスマートフォンで生成した鍵の質をどのように担保しているのか気になります。
先ほど閲覧したところ、上記引用箇所の多くは削除されていました。公開鍵が本当に通信相手のものであることをどのように検証するのかについては明らかではないようです。 LINE サーバーが介在する形であれば、鍵をすり替えることで別のユーザーになりすますことが可能でしょう。または、 LINE アプリに何か細工をする方がより簡単でしょう。
ECDH 鍵はその場限り (ephemeral) という説明がないので Perfect Forward Secrecy ではないと考えられ、望ましくないという意見もあるようです。 LINE サーバーとの間に安全な通信路を確立する目的で ECDH 鍵を用いる場合、 LINE サーバーが用いる秘密鍵の漏洩は全てのユーザーに影響を与えうるため PFS は非常に重要です (TLS を用いた Web サーバーでも同様です) 。一方ユーザー間でメッセージを暗号化する場合、ユーザー所有の ECDH 鍵についてはそのユーザーに影響が限定されます。通信相手ごとに必要なその場限りの鍵生成とユーザー所有の ECDH 鍵を利用した鍵交換にかかる計算量と ECDH 鍵漏洩のリスクを天秤にかけて PFS を採用しないという判断かもしれません。
通信の秘密という観点ではメッセージの内容だけではなく誰と通信したか (または、していないか) という情報も守りたくなります。宛先を LINE サーバーで確認できない形に暗号化されるとメッセージの配送ができなくなるため、通信相手や通信の有無については秘密ではないと考えられます。
