エンドツーエンド暗号化とは？E2EEとLINEの仕組み

LINEのLetter Sealingは、2015年に導入されたLINE独自のエンドツーエンド暗号化である。
情報セキュリティ企業で暗号実装の検証業務に携わっていた頃、「うちはTLSで暗号化しているのでE2EEです」という仕様書に何度も出会い、そのたびに区間暗号と端末間暗号の違いを図に描いて説明してきた。
CTFのCrypto問題でECDHの共有秘密を手計算で追ったとき、秘密鍵を一度も送っていないのに双方が同じ値に到達する瞬間は強く印象に残った。

LINEで「暗号化されているから安全」と言うとき、実際にはTLSによる区間暗号とE2EEが混同されがちだが、この二つは守る範囲がまるで違う。
E2EEの核心は暗号の強さではなく、サーバーを信用しないという脅威モデルの選択にあるので、Letter Sealingを見るときもまずそこを切り分ける必要があるでしょう。

Letter SealingはX25519によるECDH鍵交換とAES256-GCMを採用しており、部品の選定は標準的で堅牢です。
ただし静的な鍵ペアを使う設計のため前方秘匿性はなく、秘密鍵が将来漏れれば過去のメッセージまで遡られうる。
称賛でも断罪でもなく、設計判断とその代償を見ていきましょう。

さらに、E2EE対応の一言で見落としやすい適用範囲の穴もあります。
アルバムの画像、クラウドバックアップ、50人を超えるグループ、公式アカウントとのトーク、翻訳ボットが参加したトークは対象外で、読者自身のルームで何が守られ、何が外側に残るのかを確認してみてください。

「E2EE」とは何か——経路の暗号化との決定的な違い

E2EEは、通信の末端でだけ暗号化と復号を行い、途中のサーバーには暗号文しか見せない方式です。
HTTPSの鍵マークが示すTLSは、端末とサーバーの間の1区間を守る仕組みにすぎず、サーバーに届いた時点で本文は平文に戻ります。
ここを取り違えると、「暗号化されているなら事業者も読めない」という誤解が残ったままになり、E2EEの意味が見えなくなるのです。

TLSはどこまで守り、どこで守らなくなるのか

HTTPSの鍵マークが守っているのは、ブラウザやアプリとサーバーの間の通信路です。
セキュリティ企業で検証業務をしていたころ、TLS終端の内側でログに平文が残る設計を見つけたことがありました。
開発チームに共有したとき、「暗号化しています」という説明が、実際にはどの区間を指すのかまで言わなければ意味を持たないのだと痛感したものです。
暗号化の有無ではなく、どこで平文に戻るかが本質である、という事実が現場でははっきり現れます。

学び始めた頃の自分も、HTTPSの鍵マークを見て「これで事業者にも読まれない」と思い込んでいました。
その誤解が解けた瞬間、暗号の見え方は変わります。
TLSは盗み見を防ぐ強い仕組みですが、通信の到達点ではサーバー側が内容に触れられる設計です。
だからこそ、E2EEと同列には置けません。

「サーバを信用しない」という前提から始まる設計

E2EEが前提にしているのは、「サーバを信用しない」という脅威モデルです。
事業者が悪意を持つ場合だけではなく、サーバーが侵害された場合や法的に開示を強制された場合にも、本文そのものを守ることを狙っています。
ランサムウェアによるサーバー侵害が頻発する現状では、この考え方は悲観論ではなく、実務的な要請です。

技術の中心にあるのは鍵交換です。
E2EEでは復号鍵が送信者と受信者の端末内にのみ存在し、中継サーバーは暗号文しか保持しません。
ECDHで共有秘密を作り、そこから256ビット（32バイト）の共通鍵を導出して、本文はAESで暗号化する。
このハイブリッド構成が現代暗号の定石であり、LINEのLetter SealingでもX25519によるECDHとAES256-GCMが採用されています。
部品は標準的でも、守る対象は「通信経路の全体」であり、TLSとは守備範囲が根本から違います。

E2EEでも守られないもの——メタデータと端末

もっとも、E2EEは全能の防御ではありません。
誰が誰にいつメッセージを送ったかというメタデータは暗号化されず、端末そのものが乗っ取られれば、復号後の平文はその場で読まれます。
GCMの認証タグで改ざん検知はできますが、送受信の事実や端末侵害までは消せないのです。
経路の秘匿に強い一方で、周辺情報まで消す方式ではない、という線引きが欠かせません。

この理解があると、E2EEを「安全か危険か」の二択で見る必要がなくなります。
守るのは本文であり、守り切れないのは流通の痕跡と端末の支配です。
LINEのどのトークが対象で、どれが対象外かを考えるときも、仕様の暗記ではなく脅威モデルの帰結として整理できるようになります。
そこまで押さえて初めて、E2EEの意味が読者の手に入ります。

鍵はどう共有されるのか——ECDHと共有鍵の生成

公開鍵暗号は、公開鍵と秘密鍵を1組で運用する。
公開鍵は相手に配ってよく、秘密鍵は端末の外へ出さない。
この分担があるから、事前に合鍵を渡していない相手とも安全な通信を始められるのであって、共通鍵暗号だけで組むと「その鍵をどう安全に渡すのか」という循環に戻ってしまう。
ECDHは、その循環を抜けるための定石である。

公開鍵は配ってよい鍵、秘密鍵は絶対に出さない鍵

公開鍵は「見せるための鍵」、秘密鍵は「持ち主の中だけに置く鍵」と考えると見通しがよくなります。
鍵が2つに分かれているのは不便に見えるかもしれませんが、むしろ逆で、相手の顔も端末もまだ知らない段階から通信を始めるための仕組みです。
誰でも受け取れる公開鍵と、外に出してはいけない秘密鍵が対になっているからこそ、最初の握手が成立します。

CTFのCrypto問題で小さな数値のディフィー・ヘルマンを紙に書いて追うと、この感覚が一気に腑に落ちます。
たとえば小さな法の下で、自分の秘密数を掛け算し、相手の公開値と組み合わせていくと、途中の経路は違っても最後に同じ値へ着地する。
双方が同じ結果にたどり着いた瞬間、「秘密を送らずに秘密を共有した」という事実が目の前で形になります。
暗号が難しく見えるのは、計算そのものより、この非対称性の発想に慣れていないからでしょう。

秘密を送らずに秘密を共有するECDHの発想

ECDH（楕円曲線ディフィー・ヘルマン）の核心は、自分の秘密鍵と相手の公開鍵を組み合わせると、相手側でも同じ共有秘密に到達する点にあります。
秘密鍵そのものは一度も通信経路を流れません。
流れるのは公開鍵だけで、そこから当事者だけがたどれる共通の値を作るのがECDHです。
混ぜた絵の具は元の色に戻せない、という比喩がここでは効きます。
外から見える情報は混ざった結果だけで、元の秘密の配合までは逆算しにくいからです。

手順で見ると、まず両者がそれぞれ鍵ペアを生成し、次に公開鍵を交換し、最後に自分の秘密鍵と相手の公開鍵を使って共有秘密を計算します。
数式を先に並べるより、こうした段階を踏んだほうが「何が流れていて、何が流れていないのか」が見えやすい。
暗号実装の検証業務で、鍵導出を省略して共有秘密をそのまま鍵として使っている実装に遭遇したことがありますが、そこで問題になるのはまさにこの段差です。
共有秘密はまだ生の材料であって、用途に合わせた鍵へ整える工程が要るのです。

共有鍵ができた後——なぜ公開鍵暗号で本文を暗号化しないのか

共有秘密ができたら、そこから256ビット、つまり32バイトの共通鍵を導出し、以降の本文暗号化はAESに任せます。
公開鍵暗号は計算コストが高く、長いメッセージをそのまま扱う用途には向きません。
だから現代暗号では、最初の鍵交換だけを公開鍵暗号で行い、本文は高速な共通鍵暗号で流すハイブリッド構成が定石になります。
役割分担を切り分けると、遅い部分は短く、速い部分は長く使えるわけです。

この橋渡しを理解すると、次章のLetter Sealingが「X25519でECDH、AES256-GCMで本文」という組み合わせを採っている理由も自然に見えてきます。
特別な発明ではなく、教科書どおりの組み立てです。
しかもAES256-GCMなら、暗号化だけでなく改ざん検知までまとめて扱えるので、共有鍵を作ったあとに何を守りたいのかがはっきりする。
鍵交換は公開鍵暗号、本文は共通鍵暗号。
この分担を押さえておくと、E2EEの心臓部がかなりすっきり見えるはずです。

LINEのE2EE「Letter Sealing」の設計

Letter Sealingは、LINEが独自に開発したE2EEプロトコルであり、2015年に1対1トークへ導入された。
のちにグループトーク、音声通話へと適用範囲を広げ、現行バージョンでは標準で有効になっている。
つまり多くの利用者は、特別な操作を意識しないままE2EEを使っている状態にある。

2015年の導入と、広がっていった適用範囲

導入の順序を見ると、Letter Sealingはまず最も基本的な1対1トークから始まり、そこで運用の土台を固めてからグループトーク、音声通話へ広げていった。
いきなり全機能を同時に暗号化しなかったのは、設計を段階的に検証しやすくするためだと考えると自然です。
実装の現場では、この手の拡張は往々にしてつまずきやすいからです。

現行バージョンで標準有効という事実も見逃せない。
暗号機能が「任意の上級者向け設定」ではなく、日常利用の前提に埋め込まれているからこそ、LINEのE2EEは利用者の自覚より先に機能している。
暗号は見えにくいほど成功している、という典型でもあります。

X25519とAES256-GCM——採用されている部品

仕様書を読み込んだとき、まず安心したのは採用アルゴリズムの顔ぶれでした。
鍵交換はX25519を用いたECDH、本文の暗号化はAES256-GCM。
部品だけ見れば、どちらも標準的で堅牢です。
前章で見たハイブリッド構成を、そのまま素直に踏襲している。
独自の暗号方式を発明して売りにしているわけではなく、ここはきちんと評価されるべきでしょう。

送信時には端末上でECDH鍵ペアが用意され、鍵ペアがなければ新規に生成されてアプリのプライベートストレージに保管される。
相手の公開鍵と組み合わせて共有秘密を作り、そこから導出した鍵で本文を暗号化して、使用した鍵に関する情報とともに送る、という流れである。
暗号実装の検証業務では、アルゴリズム選定は満点なのに、プロトコル設計で失点する事例を何度も見てきた。
だからこそ「暗号は部品より組み立てで壊れる」という見方が効いてきます。

改ざん検知はできる、しかしメタデータは隠せない

AES-GCMの強みは、暗号化と同時に認証タグを生成する点にある。
これにより、途中で本文が書き換えられたメッセージは復号時に検知できる。
ここで大切なのは、メタデータ自体は暗号化されないが、改ざん検知の対象には含まれるという区別です。
つまり「外から見て内容は読めないが、内部で不正に触られたかは分かる」という関係になる。

この性質は、E2EEの説明でしばしば混同されやすい部分でもある。
隠せない情報まで消せるわけではないが、書き換えられた痕跡は残せる。
だからこそ通信の整合性は保ちやすい。
ただし、独自プロトコルであるがゆえの宿題も残る。
静的な鍵ペアを使うことで前方秘匿性がないこと、そして脅威モデルをどう置くかという問題である。
ここは次章と最終章で分けて見るのがよさそうです。

Letter Sealingが適用されない範囲

Letter Sealingは、LINE独自のE2EEプロトコルとして2015年に1対1トークから導入され、のちにグループトークや音声通話へと適用範囲を広げてきた。
現行バージョンでは標準で有効になっており、X25519を用いたECDH鍵交換で共有鍵を作り、本文はAES256-GCMで暗号化する。
GCMタグは改ざん検知に使われるため、本文だけでなくメタデータの整合性も守られるが、守られ方はトークルームの性質によって変わる。
そこが、この仕組みを理解する入口になる。

アルバムとクラウドバックアップという穴

トークルームで交わした本文が守られていても、アルバムに保存された画像・動画はLetter Sealingの対象外になる。
会話の中では鍵がかかっているのに、同じトークで共有した写真をアルバムに残した瞬間に保護の外へ出る。
この非対称は直感に反しやすく、利用者が最初に押さえるべき弱点だろう。
本文と添付物を同じ感覚で扱うと、保護範囲を見誤る。

機種変更でクラウドバックアップから履歴を復元したときも、似た落とし穴に気づかされた。
AppleやGoogleのようなサードパーティのクラウドバックアップ機能を使う場面では、メッセージはE2EEされないままクラウドストレージに保管される。
端末間の経路をどれだけ固めても、出口であるバックアップが平文なら秘匿性はそこで決まる。
鎖は最も弱い環で切れる、という原則そのものだ。

50人超のグループ・公式アカウント・ボットが入ると外れる

Letter Sealingは、相手が増えるほど自動的に広がる設計ではない。
参加者が50人を超えるグループトークではE2EEが適用されず、さらに公式アカウントやビジネスアカウントを含むトークもサーバー側では平文として扱われる。
翻訳などの機能を提供するボットアカウントが入ると、その時点以降は対象外になる。
利便性を上げるための機能が、同時に保護の前提を外していくわけだ。

友人グループのトークに翻訳ボットを招いたとき、参加者の誰もその変化に気づかなかった。
ところが、その瞬間からLetter Sealingの表示は消えた。
会話の流れは何も変わらないのに、裏側では保護が外れている。
ここにあるのは故障ではなく、機能追加が静かに暗号化の条件を変えるという、仕様上の現実である。
だからこそ、機能とE2EEは常にトレードオフとして理解しておきたい。

自分のトークルームで適用状況を確認する手順

適用状況はトークルームごとに確認できる。
右上のメニューアイコンから設定画面を開き、最下部までスクロールすると、そのトークルームにLetter Sealingが適用されているかどうかの表示がある。
やることは単純だが、ここを見ないと自分の会話がどの範囲で守られているか分からない。
見た目の会話と、実際の保護範囲は一致しないことがあるからだ。

この表示を確かめる意味は、安心のためではなく、境界を把握するためにある。
LINEのLetter Sealingは、1対1トークを起点に2015年から広がってきた標準のE2EEだが、どこでも同じように働くわけではない。
アルバム、クラウドバックアップ、人数の多いグループ、公式アカウントやボットの参加――これらの条件を並べて見ると、保護は万能ではなく、使い方に応じて設計された地図だと分かる。
どこまでが守られる領域かを、自分の手で確かめてみてください。

前方秘匿性という宿題——Signalの設計との比較

前方秘匿性とは——鍵が漏れた「後」の話

前方秘匿性とは、長期的な秘密鍵が将来漏洩しても、過去にやり取りしたセッション鍵までは復元できない性質です。
暗号の安全性を「鍵が無事なあいだ」ではなく、「鍵が漏れた後に過去へどこまで被害が及ぶか」で測る考え方であり、E2EEを名乗る方式同士を比べるときの物差しになります。
実装が見た目どれだけ同じでも、この一点で保護範囲はまるで変わるのです。

暗号実装の検証では、前方秘匿性のないプロトコルに対して「では3年前のログが今日漏れた鍵で全部読めますね」と指摘した瞬間、設計者がその含意を初めて理解する場面がありました。
抽象論に見える性質でも、保存された暗号文とひもづくと話は急に具体的になる。
読者もここを押さえると、E2EEの品質差を見落としにくくなります。

ダブルラチェット：鍵を使い捨てる設計

Signalプロトコルのダブルラチェットは、2013年に考案され、DHラチェットと対称鍵ラチェットを組み合わせて、メッセージのたびに鍵を更新します。
ここが暗号の美しいところなのですが、「鍵を進める」という操作が一方向ハッシュのような単純な仕組みで成立しているため、今の鍵から昔の鍵へ戻れません。
筆者が論文を読んだとき、この単純さこそが実装の堅牢性を生んでいると気づいた瞬間がありました。

DHラチェットは定期的に新しい共有秘密を作り直し、対称鍵ラチェットは送受信のたびに鍵を一方向に進めます。
だから、ある時点の鍵を奪っても過去のメッセージは復号できず、しかも一度侵害されても次の鍵更新で秘匿性が回復する。
これがポストコンプロマイズセキュリティ、つまり将来秘匿性です。
「漏れたら終わり」ではなく、「漏れても立ち直る」設計思想だと捉えると、Signal系の強さが見えてきます。

静的鍵を選んだ合理性と、支払っている代償

Letter Sealingは静的な鍵ペアを使うため、同じ鍵が長期にわたって使われ続けます。
そのぶん実装は単純で、非同期配送や複数端末での同時利用、スタンプやプレビューの扱いなど、状態管理が込み入る場面でも堅く動かしやすい。
ラチェット方式が抱える「端末ごとにどの鍵状態を持つか」という厄介さを避けたい場面では、この単純さには確かな合理性があります。

ただし、その代償として前方秘匿性は手放すことになる。
秘密鍵がどこかで漏れた瞬間、それ以前に保存された暗号文まで遡って読まれうるからです。
ここで問うべきなのは、静的鍵が悪いかどうかではなく、何を守り、何を交換条件として差し出しているのかでしょう。
設計の選択を読者自身が評価できる形にすると、E2EEにも品質差があることがはっきり見えてきます。

指摘された弱点と、現実的なリスクの読み方

2018年の時点で、Letter Sealingはすでに「完全性に穴があるのではないか」という警告を受けていました。
メッセージの改ざん検知が期待どおりに働かないケースに加え、前方秘匿性の不在とリプレイ攻撃の実行可能性まで指摘されていたからです。
つまり、2025年の解析は突然の失点ではなく、設計上の宿題が時間をかけて表面化した結果でした。

2018年——完全性への最初の警告

2018年に公表された問題提起で焦点になったのは、暗号そのものの強さではありません。
X25519やAES256-GCMのような部品が弱いのではなく、それらをどう組み合わせ、どこまで状態を持たせるかという設計判断でした。
前方秘匿性がなく、過去の通信を守る力が薄いままでは、鍵やセッションの扱いに少しでも綻びが出たとき、被害は通信1回分で止まりにくくなります。
ここで見えていたのは、アルゴリズムが正しくても安全とは限らないという、暗号プロトコルの基本です。

セキュリティ企業で脆弱性報告を読んでいた頃、実際の事故と「起こりうる」と書かれた現象が混同され、現場が過剰に反応する場面を何度も見ました。
その経験から、実証された攻撃と、自分が遭う確率は切り分けて読むようになりました。
2018年の指摘も同じで、怖さの源泉は事実の有無ではなく、誰の脅威モデルに刺さるのかを見誤ることにあります。

2025年——リプレイとなりすましの実証

2025年6月に開示された解析では、議論はさらに具体化しました。
過去のメッセージを再送するリプレイ攻撃、送信順の並べ替えやブロック、送信者の偽装によるなりすまし、スタンプやプレビューの平文漏洩まで、攻撃の輪郭が実証されたのです。
TLSの中間者攻撃者、あるいは悪意あるサーバーという高い立場を取れば、完全性・真正性・機密性の三つが同時に揺らぐ。
ここで問題になるのは、個々の暗号技術ではなく、メッセージの状態を厳密に管理しない設計のほうでしょう。

特に重いのは、ステートレスな設計が利用者に気づかれない形で働く点です。
並べ替えやブロックは、画面上では何事もなかったように見えてしまう。
だからこそ、攻撃が「成功したかどうか」だけでなく、「気づけたかどうか」まで含めて評価しなければなりません。
見えない改変は、後から検証しにくい。
そこが、この攻撃群の厄介さです。

それでも使う私たちが、どう受け止めるべきか

LINE側は指摘の妥当性を認めつつ、問題が独自プロトコルの設計そのものに内在するため、緩和策は限定的だとしている。
この返答は軽くない。
独自プロトコルを選ぶということは、柔軟さを得る代わりに、後から直しにくい負債を抱えることでもあるからです。
導入から10年を経て請求書が届いた、と見ると構図はわかりやすいでしょう。

ただし、一般利用者の判断はそこまで悲観的である必要はありません。
Letter Sealingがあることで日常的な盗聴リスクは下がっており、「E2EEがないよりはるかに安全」という評価は揺れません。
実証された攻撃は、いずれも高い権限や特定の攻撃位置を要します。
だから、無差別に狙われる前提で怯えるより、自分が誰から何を守りたいのかを書き出してみるのが先です。
標的型の相手を想定するなら要注意、日常の会話の保護が主目的なら十分に意味がある。
脅威モデルを言葉にすると、使い続ける理由も、距離を取る理由も、ずっとはっきり見えてきます。