ピアツーピア暗号化ファイル転送：技術ガイド

P2Pファイル転送ではファイルが一切サーバーに触れない—これは個人情報保護法（APPI）の観点で非常に魅力的な性質だ。WebRTCはRFC 8825〜8837で標準化されており、DTLS 1.3上の暗号化データチャネル、ICE・STUN・TURNによるNATトラバーサル、WebSocketまたはHTTPによるシグナリングを提供する。Snapdrop、Wormhole.app、Magic Wormholeといったツールがこのモデルの実用性を証明している。シグナリングハンドシェイク、NATトラバーサルの落とし穴、暗号化のレイヤリング、クラウドリレーとの得失について解説する。

P2PをファイルJobs転送に使う理由

魅力は明快だ。サーバーがファイルを保存せず、転送サービスの帯域幅料金が発生せず、送信者のアップロードがそのまま受信者のダウンロードになる中間コピーがない。同じギガビットLAN上の2ユーザー間で10GBを転送する場合、P2Pは80秒で完了できるが、クラウドリレーは遠くのサーバーへのアップロードと再ダウンロードで帯域幅使用量と遅延が倍になる。プライバシー面でも、ファイルバイト列は送信者と受信者のデバイスにのみ存在する。トレードオフ：双方がオンラインでなければならず、NATトラバーサルが失敗することがあり、接続速度は遅い方の参加者のアップロード回線に依存する。

トランスポートとしてのWebRTCデータチャネル

WebRTCは映像・音声プロトコルとして始まったが、RTCDataChannelが任意のバイナリメッセージ転送を提供する。内部的にはデータチャネルはDTLS 1.3上のSCTP over UDPで動作する。DTLSレイヤーがハンドシェイク中にネゴシエートされたAES-128-GCMまたはChaCha20-Poly1305で機密性と認証済み整合性を提供する。ファイル転送では、信頼性のある順序付きチャネルを作成し、ファイルを16KBまたは64KBのメッセージにチャンク分割し、bufferedAmountThresholdでフロー制御しながら順次送信する。

シグナリングサーバーの役割

WebRTCは接続情報（SDPオファーとアンサー、ICE候補）をピア間で交換するためにシグナリングサーバーを必要とする。シグナリングサーバーはファイルバイト列でなく、約5KBの接続メタデータのみを中継する。Node.js、Python、またはGoのWebSocketベースのシグナリングサービスが数百行のコードでこれを処理する。Firebase Realtime Database、Supabase Realtime、Pusherがすべてシグナリングバックエンドとして機能する。シグナリングサーバーは誰がいつ誰と通信しているかを把握するが、ファイル内容は一切見えない。ほとんどのP2Pファイル転送サービスがシグナリングを無料で運用する理由はこの帯域幅の軽さにある。

NATトラバーサル：STUN、TURN、ICE

ほとんどのデバイスはNATの背後にあり、直接IP接続が不可能だ。ICE（Interactive Connectivity Establishment、RFC 8445）が複数の接続経路を試みる。STUN（RFC 8489）はピアが公共STUNサーバーを通じて自身のパブリックIPとポートを発見できるようにする。Googleがstun.l.google.comを無料で運用している。両ピアが適切なNAT（フルコーンまたは制限コーン）を持っていれば、直接UDP接続が機能し、約70パーセントの確率で成功する。シンメトリックNAT、企業ファイアウォール、CGNATの場合はTURN（RFC 8656）がサーバー経由でトラフィックを中継する。TURN サーバーは実際のファイルバイト列を運ぶため高コストだ。実環境では10〜30パーセントのP2P転送がTURNにフォールバックすると見込まれる。

DTLSの上への暗号化レイヤリング

DTLSはすでにWebRTCデータを暗号化しているため、追加のアプリケーション層暗号化は二重の保護となる。DTLSハンドシェイクはピア証明書を認証するが、WebRTCは通常、IDを検証しない自己署名証明書を使用する。AES-256-GCMとシグナリングランデブーから派生した共有秘密によるアプリケーション層暗号化がID保証を追加する。Magic WormholeのSPAKE2 PAKE（Password-Authenticated Key Exchange）は短い人間が読める語句から強力な鍵を導出し、シグナリングサーバーが侵害されても復号できない。

P2Pファイル転送のチャンク戦略

WebRTCデータチャネルにはメッセージサイズ制限（ほとんどのブラウザで256KB）がある。互換性のために1メッセージあたり16KB〜64KBでチャンク分割する。bufferedAmountとbufferedAmountLowThresholdでバックプレッシャーを実装し、バッファが1MBを超えたら送信を一時停止し、256KBを下回ったら再開する。整合性のために各チャンクをSHA-256でハッシュし、そのハッシュを先に送信するマニフェストに含める。受信者が再組み立てし、ハッシュを検証し、File System Access APIまたはBlobダウンロードでディスクに書き込む。

モバイルとクロスデバイスの考慮事項

デスクトップ間のP2Pはうまく機能する。モバイル〜デスクトップ間には複雑さが伴う。モバイルブラウザはアグレッシブなタブサスペンションを実施するため、送信者はブラウザタブをフォアグラウンドに保つ必要がある。iOS SafariのデータチャネルはChromiumに比べ信頼性が低い実績がある。同一Wi-Fi上のモバイル〜モバイル転送では、AirDrop（iOS/macOS）とNearby Share（Android）がブラウザP2Pをダイレクトデバイスプロトコルで上回る。

P2P特有のセキュリティ脅威

P2Pにはクラウドリレーにない脅威がある。IPアドレスの開示：直接接続により各ピアのパブリックIPが相手に露出し、内部告発や活動家などプライバシーに敏感なコンテキストでのユーザー特定のリスクがある。マルウェア配布はサービス運営者がファイル内容を見ないため監視が困難だ。シグナリングサーバーへの接続枯渇によるサービス妨害にはレート制限が必要だ。

HexaTransferはクライアントサイドAES-256-GCM暗号化を備えたクラウドリレーモデルを採用し、P2Pのプライバシーの利点の大部分を維持しながら、非同期転送とマルチ受信者サポートで上回っている。詳細は https://hexatransfer.com で。無料、アカウント不要、最大10GB。