LINEはE2EE （エンドツーエンド暗号化）を標榜している。E2EEという言葉は日本では普及しているとは言えない。言葉を知っている人でも、どんな脅威モデル（どのような条件下で攻撃が防げるか）を想定するべきか、知っている人は多くない。なぜ今、LINEのE2EEを検証しなければいけないか。
LINEは、日本・台湾などで社会インフラ級のメッセージ基盤となっている。個人間の多くのコミュニケーションが暗黙にLINEを仮定しているほか（「LINE、交換しよ？」などと）、政府・地方政府（自治体）機関や企業の多くがLINEを利用し、依存している。
LINEは単なるソーシャルメディア（SNS）ではない。このような巨大な基盤がE2EEを標榜している以上、LINEが実際にE2EEが本来想定する脅威に耐えられるかどうかは検証が必要である。
Black Hat Europe 2025 (BHEU2025) における、2025年12月11日に行われたオーフス大学のアランハ准教授らによる発表は、これに重大な疑問を提起するものだった。
今回の記事では個人アカウント間のダイレクトチャット・通話・グループチャット・グループ通話を扱う。LINE公式アカウント（自治体や企業等から個人への告知=B2Cによく使われる）、および50人以上のグループチャットにはエンドツーエンドの暗号化は存在しない。公式アカウントのシステムにかつてあった情報漏洩問題については、以下の記事を参照。
これはinnovaTopia限定の独自記事です。
【編集部解説】
時間の少ない人向けの要約
- LINE はスタンプ (stickers) のおすすめ機能で送信前のメッセージにある単語を推測できる情報（関連するスタンプの組み合わせから含まれる単語を高精度で推測可能）をデフォルトではトランスポート暗号化のみでサーバに送信しています。
→ 設定でスタンプのサジェスト機能を切ることで回避できます。 - URLのプレビュー機能は送信時にURLを生でサーバに送信しています。
→ 秘密の、あるいは権限を持つようなURLをLINEで送信するような場合は、設定でURLのプレビュー機能を切ることでこのリークを回避できます。 - 現状では、LINE のメッセージの機密性自体が損われることは、公開情報と編集部の検証範囲では、上記の点以外には発見されていません。
- エンドツーエンド暗号化 (E2EE) を期待する場合は、グループチャットを50人以上にしてはいけません。50人以上のグループチャットでは、 Letter Sealing v2 は無効化されます。
innovaTopia編集部は、脆弱性の詳細な発表が行われる前の2025年12月5日に独立してメディアとして世界で初めてリプレイ攻撃を実証しています。これについては、以下の記事が初出です。
E2EEの真の意義とは何か
E2EEの一般的な脅威モデルは、例えば以下のような攻撃者を想定します（E2E攻撃者）。
- サーバ侵害
- 悪意ある内部者
- 国家による強制・介入
エンドツーエンド暗号化（E2EE）が想定する脅威モデルにおいては、「HTTPSが安全であること」や「サーバが正直に振る舞うこと」は、前提条件としては不十分です。HTTPS（TLS）は通信経路上の盗聴や改ざんを防ぐ仕組みであって、あくまで「クライアントとサーバ間」の安全性を保証するものに過ぎません。一方、E2EEはその一段先、すなわちサーバ自体が侵害される、あるいは悪意を持つ可能性がある状況においても、通信内容の機密性・完全性・認証性を維持することを目的として設計されるものです。
これは理論上の極端な想定ではなく、実務的にも広く共有されている前提です。悪意ある内部者、法的・政治的圧力による不正なサーバ操作、あるいは国家レベルの攻撃者による侵害は、現実のサービス運用において完全に排除できるものではありません。そのためE2EEは、「サーバを信頼しなくても安全である」こと、言い換えればサーバが攻撃者であっても成立する安全性を目指すのです。この点こそが、E2EEがHTTPSや通常のサーバ側暗号化と本質的に異なる理由であり、E2EEの“whole point（存在意義）”とされているゆえんなのです。Signal や Matrix などのプロトコル、MLS (Messaging Layer Security) などでも、これは前提とされています。
MLS adopts the Internet threat model [RFC3552] and therefore assumes that the attacker has complete control of the network. It is intended to provide the security services described in Section 8.2 in the face of attackers who can:
- Monitor the entire network.
- Read unprotected messages.
- Generate, inject, and delete any message in the unprotected transport layer.
While MLS should be run over a secure transport such as QUIC [RFC9000] or TLS [RFC8446], the security guarantees of MLS do not depend on the transport. This departs from the usual design practice of trusting the transport because MLS is designed to provide security even in the face of compromised network elements, especially the DS.
RFC 9750 The Messaging Layer Security (MLS) Architecture – §8. Security and Privacy Considerations
LINEヤフー社の公式見解──E2EEは破られない前提で設計されているのか？
LINEヤフー社は、HTTPS・サーバが侵害される事態に関しては、E2EE対象のメッセージ内容は保護される設計としていると以下のように明言しています。
編集部の質問とLINEヤフー社の応答（クリックして展開）
編集部: LINEヤフー様として、HTTPSが破れる状況下、またはサーバが乗っ取られる状況下では、セキュリティやプライバシーを（少なくとも通常の意味では）確保することは考えていないという認識でお間違いございませんでしょうか？
LINEヤフー: 結論から申し上げますと、そのような認識ではございません。
弊社が「Letter Sealing」という名称で提供しているエンドツーエンド暗号化（E2EE）は、いかなる状況においても当事者以外にはメッセージ内容を閲覧されないことを目指し、ユーザー個人のプライバシーを最大限保護することを設計思想としております。
LINE では、通信路の HTTPS（TLS）による保護に加え、対象となるメッセージ、メディアや通話については Letter Sealing を適用しています。Letter Sealing が有効な範囲については、メッセージ内容はクライアント側で暗号化されてから送信され、サーバ側では復号できない設計となっております。
このため、HTTPS が仮に破られた場合や、一部サーバが侵害された場合であっても、端末自体の安全性と暗号技術の前提が成り立つことを条件に、E2EE の対象となるメッセージ内容は暗号化された状態で保護され、ユーザー個人のプライバシーが守られることを前提として設計しております。当社としては、HTTPSが破られる状況下、またはサーバが乗っ取られる状況下においても、運用・インフラ・端末側での多重の防護を行い、利用者の皆さまのセキュリティ・プライバシーを最大限確保できるよう取り組んでおります。
つまり、E2E攻撃者を想定していないわけではなく、想定して設計を行っていたことが分かります。
また、LINEヤフー社は、「私たちを信頼してください」ではないセキュリティを目指しているとして、第三者による認証、情報公開、レビュー、学術コミュニティやメディアとの対話などを重視しているとして、以下のように回答しています。
編集部の質問とLINEヤフー社の応答（クリックして展開）
編集部: 現状の LINE の実装は、LINEヤフー様、およびそのサーバ、認証局などを信用することで成り立っていると私どもは考えております。日本国内では信用されるかもしれませんが、海外利用者にとって、LINEは海外アプリになります。LINEはグローバル展開されていらっしゃるようですが、海外での信用リスクについてどのようにお考えでしょうか？
LINEヤフー社:
弊社としては、「事業者を信頼してください」というだけに依存するのではなく、次のような取り組みによって“検証可能な形での信頼”を積み上げることを重視しています。
- 暗号技術・プロトコルの仕様を Encryption Whitepaper や Encryption Report などで公開し、第三者による技術的レビューが可能な状態にしていること
- ユーザ情報の取り扱いや法執行機関からの要請に対する対応方針・実績を、Transparency Report 等として定期的に公開していること
- ISO/IEC 27001 などの情報セキュリティに関する外部認証や、第三者によるセキュリティ評価を継続的に受けていること
- 脆弱性報告プログラム等を通じて、社外のセキュリティ研究者からのフィードバックを受け付けていること
また、今回のように、学術コミュニティからの指摘や、メディアの皆さまからのご質問を受けて議論を深めることも、グローバルでの信用リスクを下げるうえで重要だと認識しています。
なお、脆弱性報告プログラムはセキュリティ侵害が実際に発生したとして中断される事態になっています。
そのほか、LINEヤフー社は、ユーザの通信内容を第三者やLINEヤフー社自身が恣意的に閲覧できるようにする目的で暗号を弱めさせるようなことをしないとしています。
編集部の質問とLINEヤフー社の応答（クリックして展開）
編集部: 貴社のなかで、以下のような理由からあえて「完璧な」暗号を実装することを避けているなどのお考えはございますでしょうか？
- ユーザ体験の向上、またそのためのマーケティング上の理由のため
- 犯罪捜査を妨げないようにして、また捜査に協力しやすくするため
LINEヤフー社: まず前提として、当社はユーザの通信内容を第三者や当社自身が恣意的に閲覧できるようにする目的で暗号を弱めさせるようなことはせず、今後も決して行わない方針です。
また、使用している暗号アルゴリズムは AES、ECDH、SHA-2 など、広く標準化・検証されたもののみであり、独自方式で「強度を落とす」といった実装はしていません。
前述の通り、当社は暗号技術・プロトコルの仕様・透明性レポートを定期的に公開しており、第三者による検証が可能な仕組みで取り組んでいます。
今回のご指摘を含め、学術コミュニティや標準化団体における議論も踏まえつつ、E2EE プロトコルの設計については今後も継続的に見直し・改善を行っていきます。
しかし、LINEヤフー社の公式の応答においては、「閲覧」などの言葉を使い、E2EEの原則のうち「機密性」に終始した説明をしているようにも読めます。E2EEは暗号化されて読めないだけではなく、改ざん防止や、送信元偽装の防止などを備えてなければなりませんが、それについてはあまり触れられていません。
とはいうものの、以下のようにLINEヤフー社は今後改善していくとしています。
今回のご指摘を含め、学術コミュニティや標準化団体における議論も踏まえつつ、E2EE プロトコルの設計については今後も継続的に見直し・改善を行っていきます。
LINEヤフー社 (LY Corp) 広報
研究者の見解：それでも現実的な脅威だと考える理由
オーフス大学の研究者らは、今回の攻撃が「実験的なセットアップ」に基づくものであること自体は認めつつも、サーバが攻撃者の支配下に置かれる状況は、E2EEにおいては十分に現実的な脅威モデルであると指摘しています。彼らの想定では、中間者攻撃（MITM）を成立させる必要すらなく、LINEのサーバそのものが侵害された場合、あるいは悪意ある内部者や国家による強制を受けた場合に、同様の攻撃が成立し得るというのです。
研究者らは、これらの攻撃に中間者攻撃（MitM）は一切必要ないと繰り返し強調しています（ソース: 私信 [p.c.]）。LINEのサーバが侵害されている、あるいは攻撃者の支配下にある場合、それだけで攻撃は成立するのです。これはLINEヤフー社の一部説明や海外メディア報道に見られる「MitMが前提」という理解とは明確に異なるものです。
このような状況は、E2EEが本来対処すべき典型的な脅威であり、むしろE2EEが存在する理由そのものだと研究者は位置づけています。特に近年、ランサムウェアなどによる企業サーバ侵害が各国で頻発している現状を踏まえると、「サーバは正直であり続ける」という前提に安全性を依存させる設計は、現実的なリスク評価として十分ではないと考えられます。研究者らは、今回指摘した脆弱性が、暗号アルゴリズムの選択ではなく、脅威モデルとプロトコル設計の前提そのものに関わる問題である点を重視しています。
研究者はさらに、LINEでは特定の条件下でE2EE自体が無効化される点を指摘しています。具体的には、参加者が50人を超えるグループチャットや、（今回の記事のスコープ外ではあるものの）公式アカウント（Official Account / Business Account）が含まれるチャットでは、エンドツーエンド暗号化は適用されません。この場合、通信内容はサーバ側で平文として扱われます。
研究者は、LINE側との協調的開示を行い、多くは「既知の制限」だが、脅威モデル更新が必要であるとしています。
研究者は、これらの特性により、LINEのサーバインフラは国家主体（や高度持続的脅威（APT））にとって極めて魅力的な標的になり得ると指摘しています。
The attack scenario is highly realistic and makes the LINE infrastructure (servers) incredibly interesting for nation-state actors to infiltrate and monitor – and potentially to use for targeted attacks.
Thomas Mogensen (p.c.), on 2025/12/19, at 18:02
これはE2EEのあるべき姿ではない
This is not how E2EE is supposed to work.
https://i.blackhat.com/BH-EU-25/BHEU25-Mogensen-LINE-Break-Cryptanalysis-And-Reverse-Engineering-Of-Letter-Sealing-Final.pdf – Page 53 より引用
内閣官房国家サイバー統括室の応答
LINE独自暗号プロトコル「Letter Sealing v2」の脆弱性に関する参考URLを添えて、以下の質問を内閣官房 国家サイバー統括室に送り、回答を得ました。
2025年12月8日に問い合せフォームから送信。その後、2回ほど電話をかけたところ、2025年12月19日、編集部に以下の質問に対する応答がありました。なお、回答の中で電気通信事業法関連については、総務省が担当しているとしています。
編集部の質問に対する日本政府の内閣官房国家サイバー統括室からの返答
この度は、ご連絡いただきありがとうございます。
いただきました照会について、以下のとおり回答します。
なお、電気通信事業法の所管は総務省となるため、当該法律に関する詳細は総務省にお尋ねいただければと思います。(1) 政府として、このLINE脆弱性に問題はないとお考えですか？
（答）現在、事実関係を確認中であり、具体的にお答えはできない。(2) 完璧な暗号化は犯罪捜査の妨げになるという観点から、政府とLINEヤフー社との間で調整をされていますか？
（答）犯罪捜査に関することは、警察庁にお尋ねいただきたい。(3) 高市政権ではサイバーセキュリティへの注力が挙げられています。国民的スーパーアプリであるLINEに、どこまでセキュリティの堅牢性を求めていかれますか？
（答）通信事業者に対しては電気通信事業法に基づき、適切な対応を求めている。
国家サイバー統括室は全府省・重要インフラを結ぶハブとして機能し、日本のサイバーセキュリティ政策における政府横断的な司令塔です。官民連携、省庁横断の中心にある組織なので、もっと前向きな回答を期待していました。
脆弱性の性質の整理──技術と実装について
研究者の整理
- グループチャットにおけるなりすまし（impersonation）
- これは完全に設計上の欠陥であると研究者は考えています。
- カウンターのエンコーディング問題（リプレイ攻撃の原因）
- これに関しては実装のミスという面も強いと研究者は考えています。
- スタンプ (stickers) おすすめと URL プレビューによる平文漏洩
- 設計上の欠陥と実装のミスの両面があると研究者は考えています。
LINEヤフー社も「標準的な暗号アルゴリズム」を用い、それらは弱めていない点を強調していますが、アルゴリズムが悪いわけではなく、プロトコルと実装上の問題なのです。
| 脆弱性 | 分類 | 影響する性質 |
|---|---|---|
| リプレイ／順序入替／遮断 | 実装＋設計 | 完全性 |
| なりすまし（グループ・1対1） | 設計 | 完全性・認証 |
| URL・スタンプ漏洩 | 設計＋実装 | 機密性 |
| 鍵更新の欠如 | 設計 | 前方秘匿性 |
リプレイ・順序入替・遮断問題
これは、同一メッセージが再送・並び替え・欠落しても検出できないという問題です。メッセージ状態の一貫性（つまり、チャット履歴）が保証されないということです。
原因としては、カウンタ管理とそのエンコード方式 (Zig-zag encoding)、メッセージのタイムスタンプをサーバ受信時刻に依存し、暗号学的に記録していないこと、クライアント側での検証不足が挙げられます。
当編集部でも、特定の構造をもったカウンタがあり暗号学的認証で適切にカバーされていないことを発見・着目して、発表が行われる前の2025年12月5日に独立にリバースエンジニアリングに基づく実験的なリプレイ攻撃試験を行い、LINEヤフー社に報告した次第になります。
研究者も「仕様上の制限として既知だった」とLINE側も認めていたとしています。これにはUX優先の設計判断が背景にあるとしています。
あなたがリプレイ攻撃の再現に成功したと聞けるのはすばらしい！
It’s great to hear that you managed to reproduce the replay attack!
LINEにおいて当編集部が発表に先立ってリプレイ攻撃の再現に成功したことについて、アランハ准教授のコメント（日本時間2025年12月19日午前7時）
グループチャット・1対1チャットにおけるなりすまし問題
この問題は、1対1鍵交換の拡張としてグループ鍵を設計していることによるもので、グループ鍵自体は個人のアカウントに厳密に結びついたものではないことによるものです。クライアント側では充分な検証ができないため、サーバが正直に振る舞うことに依存することになりますが、これはE2E脅威モデルにはそぐわないものです。
研究者からの情報によれば、このなりすまし問題はグループチャットに限らず、1対1チャットにおいても（E2E攻撃者のモデルのもとでは）成立するといいます。
URL・スタンプによる平文の部分的漏洩
これは、メインの暗号プロトコルにおいて機密性が直接破られているわけではありません。メッセージ本文とは別経路で入力した情報がURLプレビュー・スタンプ (stickers) のおすすめの機能によって、外部送信されるという問題です。また、スタンプのおすすめは、ユーザー操作（入力）時点で発生するという点も問題です。
スタンプのおすすめ機能においては、直接平文をサーバに送信しているわけではありません。ただし、研究者によれば、ある単語に関連する複数スタンプの同時取得の組み合わせから、高精度でユーザが入力中の単語が推測可能であるとしています。
これに対して、LINEヤフー社は、研究者に対する応答の中で、「スケーラビリティ・利便性とのトレードオフ」、ユーザが「オプトアウト可能な設計」であり、設計上の妥協であることを明示しています。また、スタンプの送信やリアクションは明示的に E2EE に含まれていません。
これに対して、研究者側は、スタンプ (stickers) や URL のプレビューが「非センシティブ」であるとするという前提そのものに疑念を呈しているほか、この機構が現在はそうでなくても、将来において監視・検閲・スパイウェア的に利用される懸念も示していました。
前方秘匿性（Forward Secrecy）の欠如
詳細は省きますが、前方秘匿性を実現するためには、往復の同期通信を行った上でのラチェット機構（例、Signal の Double Ratchet）のような、逆転を許さない仕組みが必要になります。
LINEで指摘されている設計上の特徴として、鍵マテリアルが長期間固定で、継続的に動作するラチェット機構のようなものが存在しないことが挙げられます。
これが影響するのは鍵が漏洩したときです。Signal では極めて限られた通信しか解読できない（影響範囲が狭い）のですが、LINEだとその通信チャネルのほぼ全てが破られてしまいます。
ケース・スタディ：Telegram もあまり安全ではない
LINEに脆弱性と聞くと、代替手段として Telegram を思い浮かぶ方も多いかもしれません。実際、Telegram メッセンジャーは「海外における LINE」といっても過言でないほど、日本におけるLINEのように国際的に使われています。
しかし、そもそも Telegram はデフォルトで E2EE ではありません。通話は E2EE が実装されていますが、テキストチャットにおいては、多くの人が知らない機能である「シークレットチャット」（1:1対話のみ）を明示的に開いたときのみ、E2EE が実現します。シークレットチャットは単一端末でしか使えないなど、非常に使い勝手が悪いため、使っている人が少ないのが実情です。
Telegram は、履歴を自動的に消す機能などがあり、一見非常にプライベートに見えますが、暗号学的には保証されていることは少ないのです。実際に E2EE である、「シークレットチャット」を実現しているプロトコルも Telegram の独自プロトコルである「MTProto」であり、これに対する暗号学者の見解も分かれています。ましてや、グループチャットやチャンネルにおいては、E2EE 暗号化のオプションもありません。ブログのようなものです。
編集者のひとこと
私は、個人的には Telegram は暗号的に重要な用途においては信用していません。これは個人的な見解です。
これらを踏まえると、LINE は「一応」デフォルトですべての人に E2EE を提供しようとしていますし、今後プロトコルを改善すると主張しているので、メインストリームの（ポピュラーな）商用プラットフォームとしてはそれほど悪くないということが分かります。
争点の核心：「E2EEが守るべきもの」をどこまで定義するか
現在のLINEの「E2EE」は限定された脅威モデルのもとでは成立しており、何も無いよりはるかに良いものです。しかし、E2EEの真の精神としては不十分なのが現状です。LINE社は自社や第三者（おそらく政府等）が介入することができるように暗号を恣意的に弱めることはないと明言しています。脅威モデルをアップデートし、より多様な攻撃に耐えられるようにすることが必要なのではないでしょうか。
今後に向けて：ホワイトハッカーを守り育てる方向性へ
日本においては、独立セキュリティエンジニア・ホワイトハッカーが、攻撃試験を行ってベンダー等に報告を行う場合の攻撃試験を行う者に対する法的保護が充分ではありません。下手をしたら善意でセキュリティをテストしているのに、警察に捕まりかねない状態（許可なくアクセス制御を回避する形になれば不正アクセスの構成要件に触れ得る）です。
編集者注: 私も、今回の試験を行うにあたり、非常にひやひやしました。
脆弱性の報告制度や責任ある開示の制度はここ10数年のあいだに整備されてきました。しかし、最初に脆弱性をチェックする行為は、法の運用次第で刑事立件されうる状態が続いています。
このような状況下では、法的措置を恐れてセキュリティを誰も調べない結果、脆弱性が放置される状況になりかねません。善意のセキュリティ検査者に対する法的保護を強化するべきではないのでしょうか。これは、日本の国家レベルのサイバーセキュリティを強化するためには、避けて通れない道です。
LINE Security Bug Bounty Program （プログラムは2025年12月3日から現在停止中）
【用語解説】
E2EE（エンドツーエンド暗号化）の持つべき特性（再掲）
- 機密性（confidentiality; 内容が中間者によって解読されない）
- 完全性（integrity; いかなる改竄も検出可能）
- 真正性（authenticity; 正しい相手と通信していることを検証可能）
- 前方秘匿性（forward secrecy; 将来の鍵の漏洩によって過去の通信を解読できない）、場合によっては省かれる文献もある
ホワイトハッカー: 「ハッカー」とは元来コンピュータの専門家くらいの意味で、本来悪いことをする人という意味ではないが、攻撃者としての悪印象が先行してしまったので、善意でセキュリティに携わる人の名称として用いられる。
スレットモデル（Threat Model／脅威モデル）: 情報セキュリティの分野で使われる考え方で、「誰が、どのような立場で、何を守りたいのか／何を狙ってくるのか」を整理し、どこまでの攻撃や事故を想定して対策するのかを明確にする枠組みのこと。
脅威モデルでは主に、
- 守る対象（資産）：個人情報、金銭、機密文書など
- 攻撃者（脅威主体）：外部の攻撃者、内部関係者、国家機関など
- 攻撃手法：盗聴、改ざん、なりすまし、内部不正など
- 想定する前提条件：通信は安全か、サーバは信頼できるか、端末は安全か
といった点を明確にする。
重要なのは、「絶対に安全」なシステムは存在しないという前提に立ち、「このシステムは、どこまでの脅威から守れるのか」「逆に、何は守れないのか」をあらかじめ共有しておくことである。これにより、過剰な期待や誤解を防ぎ、目的に合った現実的なセキュリティ設計や評価が可能になる。
【参考リンク】
情報セキュリティ早期警戒パートナーシップガイドライン – IPA （情報処理推進機構）
Four Attacks and a Proof for Telegram – Telegramに対する攻撃を記述した paper。
Line-Break – 研究者グループ: Diego F. Aranha, Associate Professor, Adam Blatchley Hansen, PhD student, Thomas Kingo T. Mogensen, MSc. らによる脆弱性の公式サイト。
【編集部後記】
この記事を書いた私も、E2EE プロトコルを実験的に制作・運用した経験があります。標準暗号スイートを使うのはあたりまえとして、その上に独自にプロトコルを作ることの難しさは、身を以って実感しています。特に、E2EE の前方秘匿性 (forward secrecy) を提供することは、本当に大変です（私のデザインでも、epoch-based secrecy に妥協している場合がかなりあります）。前方秘匿性が LINE で現状提供されていないのも、全く理解できないものではありません。LINEは改善の姿勢を示しています。LINEは日本を代表するアプリのひとつです。LINEの改善が日本発のソフトウェア・システムへの信頼性を向上させることを願っています。編集部としても今後の LINE のアップデートを見守っていきたいと考えています。
