TLSとエンドツーエンド暗号化:知っておくべき違い

TLS（ Transport Layer Security ）はデータを端末からサーバーへ転送する間だけ暗号化し、到着時に復号します。つまりサーバー運営者はファイルを平文で読むことができます。エンドツーエンド暗号化（ E2EE ）は送信者の端末上でコンテンツを暗号化し、受信者だけが鍵を持つため、サーバーは平文のデータを見ることがありません。ファイル転送において、 TLS はネットワーク盗聴者から守りますが、プロバイダ自身からは守りません。 E2EE は両方から守ります。ブラウザに表示された鍵のアイコンはどちらが実際に使われているかを教えてくれません。

TLS が実際に守るもの

TLS 1.3 は RFC 8446 で標準化されており、すべての HTTPS 接続を支えるプロトコルです。 X25519 などの曲線を使った ECDHE でセッション鍵を交換し、 X.509 証明書でサーバーを認証し、 HTTP トラフィックを AES-128-GCM または ChaCha20-Poly1305 で包みます。これはカフェの Wi-Fi 攻撃者や通信内容を読もうとする ISP に対して優れた保護を提供します。

TLS が行わないこと：ロードバランサーで終端されます。典型的なファイル共有サービスに3 GB の動画をアップロードする場合、 TLS はエッジで復号され、平文のファイルが S3 バケット、トランスコードパイプライン、場合によっては ML によるコンテンツスキャン処理に渡り、最終的に受信者のダウンロードストリームに新しい TLS セッションで再暗号化されます。サービス側はすべての段階でファイルを完全に読むことができます。

エンドツーエンド暗号化の境界

真の E2EE は暗号化の境界をサーバーから端末に移します。送信者のブラウザまたはクライアントで、対称鍵（通常は AES-256-GCM ）がメモリ上で生成されます。ファイルは1バイトも端末の外に出る前にチャンク単位で暗号化されます。暗号文は TLS 越しにサーバーに送られ、サーバーは不透明なデータを保存します。受信者は別のチャネル経由で復号鍵を受け取ります。最も一般的な方法は、ブラウザがサーバーに送信しない URL フラグメント # の後に含める方式です。

このモデルではサーバーは単純なストレージ層に過ぎません。令状を持った人も、データベースアクセス権を持つ不正な従業員も、ディスクスナップショットを読んだクラウドプロバイダも、得られるのは暗号化されたバイトのみです。これが HexaTransfer のアーキテクチャです。転送ごとの鍵をクライアントサイドで導出し、オリジンには送信しない AES-256-GCM を採用しています。

TLS のみ方式と E2EE の比較

| 特性 | TLS のみ | エンドツーエンド暗号化 | |---|---|---| | 転送中の暗号方式 | AES-128/256-GCM | AES-256-GCM（TLS も使用）| | サーバーが平文を見るか | 見る | 見ない | | 鍵の場所 | サーバー管理 | 送信者の端末 | | 令状への耐性 | なし | 強い | | プロバイダによるコンテンツスキャン | 可能 | 不可能 | | 鍵紛失時の復旧 | プロバイダが支援できる | データは復元不能 | | 代表的なサービス | Google Drive 、 Dropbox | HexaTransfer 、 SwissTransfer E2EE モード |

鍵交換が実際に機能する仕組み

E2EE で難しいのは暗号方式ではありません。 AES は25年間安定して機能しています。難しいのは、サーバーに見られずに送信者から受信者に鍵を届けることです。ファイル転送サービスでは主に3つのパターンが使われます。

1つ目は URL フラグメントのトリック：リンクは https://hexatransfer.com/d/abc123#key=xyz のような形で、 # 以降がブラウザに残ります。 JavaScript がローカルで読み取り復号します。2つ目はパスワードベースの暗号化：送信者がパスフレーズを選び、 PBKDF2 （ RFC 8018 ）または Argon2id で60万回以上の反復を行い、 Signal や電話でパスワードを帯域外で共有します。3つ目は libsodium の crypto_box などを使った公開鍵交換：受信者が X25519 公開鍵を公開します。

TLS だけで十分なケース

すべてのファイルに E2EE が必要なわけではありません。記者にプレスリリースを共有する、グループチャットにミームを送る、公開されたマーケティング用 PDF を配布する、といった場合は TLS のみのサービスで十分です。もともとデータが機密でなければ、プロバイダが読んでもリスクはゼロです。プレビュー、サムネイル、ブラウザ内編集などの利便性を優先でき、これらの機能はサーバー側で平文へのアクセスが必要です。

計算式が変わるのは、医療画像（ HIPAA 45 CFR 164.312(a)(2)(iv) が対象の DICOM ファイル）、 PCI DSS 4.0 要件3.5.1 下の財務諸表、法的証拠開示資料、 M&A 関連文書、または GDPR 第32条下で EU の個人データを含むものです。ここでは「プロバイダが技術的に読める」こと自体がコンプライアンス上の問題になります。単なるプライバシーの好みではありません。

誰も話さないメタデータの問題

完全な E2EE であっても、サーバーはメタデータを見ます。アップロードのタイムスタンプ、ファイルサイズ、送受信者の IP アドレス、ユーザーエージェント文字列、転送時間です。脅威モデルにトラフィック分析が含まれる場合、たとえばジャーナリストが情報源とやり取りする場合などはこれが問題になります。午前3時14分に Reuters のオフィスから Istanbul の Signal 番号に147 MB のファイルがアップロードされたという事実は、内容が暗号文でも物語を持ちます。

優れた E2EE サービスはメタデータの保持を最小化します。短いログ保持期間（7日以内）、基本的な転送にはアカウント不要、転送ページにサードパーティの分析ツールなし、そして可能であれば Tor ルーティングや VPN フレンドリーなポリシーを確認してください。暗号方式より、その周辺の運用上の衛生状態の方が重要です。

主張を検証する方法

「エンドツーエンド暗号化」はそれを証明できるまでマーケティング用語に過ぎません。3つのテストで本物の E2EE と言葉遊びを見分けられます。まず、開発者ツールを開いてアップロード中のネットワークタブを確認してください。ファイルの中身が平文の multipart/form-data で送信されているなら TLS のみです。次に、復号 URL にフラグメント（ # ）が含まれているか確認してください。フラグメントがなければクライアントサイドの鍵はありません。3つ目に、当局への対応ポリシーを読んでください。法執行機関にファイルの内容を提供できるサービスは、最初から E2EE ではありません。ワーカーカナリーを公開し、暗号コードをオープンソース化（ WebCrypto API の使用を示す GitHub リポジトリ）しているサービスが最も強い保証を提供します。

機密性が重要な大容量ファイルの日常的な送信には、自社のモデルを明示しているサービスを選んでください。 hexatransfer.comでお試しください — 無料、登録不要、最大10GB。