セキュリティと脅威モデル

最終更新: 2026-08-02

Relayium は、鍵を握るのはサーバーではなくファイルや一時テキストを転送する当事者であるように設計されています。このページでは、何がどのように保護されるのか、そしてその保護の限界を説明します。

要点：同一ネットワークではリアルタイムのファイルとメッセージがデバイス間を直接流れます。ネットワークをまたぐブラウザセッションは、エンドツーエンド暗号化された暗号文だけを運びコンテンツ鍵を持たないリレーを使います。セッションごとの新しい鍵は常に使われます。加えて任意の検証コードがあり、帯域外で照合すればシグナリングの傍受も検出できます。以下に詳細を記します。

ブラウザのリアルタイムファイル暗号化（X25519 + AES-256-GCM）

ブラウザのリアルタイムファイル転送では、転送ごとに各デバイスで新しい一時的な X25519 鍵ペアが生成されます。2 つのブラウザは鍵交換を行い、共有 AES-256-GCM 鍵を導出します。各ファイルチャンクはその鍵と一意のノンスで暗号化されるため、シグナリングサーバーや中継が目にするのはファイルの平文ではなく暗号文です。CLI 転送は後述する別の直接 TLS 1.3 プロトコルを使用します。

鍵は一時的で転送ごとに独立しており、セッションをまたいで再利用されることはありません。
共有鍵は 2 台のデバイス上で導出され、いかなるサーバーにも送信・保存されません。
暗号化は WebRTC 自身のトランスポート層セキュリティの上のアプリケーション層で適用されるため、トランスポート層が侵害されても有効性を保ちます。

検証コード（SAS）——悪意あるサーバーの検出

WebRTC 標準の暗号化（DTLS）は鍵のフィンガープリントをシグナリングサーバー経由で交換するため、不正なサーバーが中間に入り鍵をすり替える可能性があります。これを検出するため、Relayium は双方の公開鍵から 6 桁の Short Authentication String（SAS）を導出し、両方の画面に表示できます。一致するコードが最も強い傍受検出保証を与えるのは、両者が帯域外で照合した場合だけです。このコードを表示して照合のために止まるかどうかは設定です——ウェブでは「高度な検証」（既定はオフ）、CLI では `--verify`。オフにして変わるのは、画面に何を表示するかと、どの手順が確認のために止まるかだけで、暗号化は変わりません。下記のコミット後開示ハンドシェイクはすべての接続で実行され、開示が一致しなければ接続を拒否します。鍵は端末上で生成され当社に送られることはなく、リレーが運ぶのは暗号文だけで、ブラウザではファイルの受信時に保存前の確認があります——ネイティブの macOS アプリは、設定された保存先（既定はダウンロードフォルダー）へ確認なしで書き込みます。この確認は勝手な書き込みを防ぐためのもので、相手が誰かを保証するものではありません。それを確かめられるのはコードの照合だけです。

単純な 6 桁のコード（約 20 ビット）は、原理的には中継サーバーが一致するコードを総当たりで作り出す余地があります。Relayium はコミット後開示ハンドシェイクでこの隙を塞ぎます。各側はまず鍵のハッシュを送ってコミットし、相手のコミットメントを受け取ってから鍵を開示します。CLI 転送は、ピン留めされた TLS 証明書のフィンガープリントをコミット後開示で交換して導出する別の SAS を使用します。これも実際に誰かが帯域外で照合したときにだけ意味を持ち、そのために止まるのが `--verify` です。

最も強い保証を得るには、まず高度な検証をオンにし、コードを帯域外——対面または音声通話——で照合してください。
2 つのコードが異なる場合は転送を中止してください。誰かが接続を傍受している可能性があります。

サーバーが見たり復号したりできない平文

本サービスは、サーバーが以下の平文を見たり復号したりできないように設計されています：

ブラウザのリアルタイムモードでは、同一ネットワークのファイルとメッセージの実体は 2 台のデバイス間を直接流れます。ネットワークをまたぐ場合は暗号文として TURN を経由し、リレーはコンテンツ鍵を持ちません。一方、シグナリングサービスは接続確立データを扱い、公開 IP、ルーム所属、時刻、選択したデバイス名、在席状況などのメタデータを見ることができます。

ファイルの内容。
ファイルの名前。
テキストメッセージの平文。
お客様の暗号鍵。

ブラウザのファイルとテキストが中継される場合（TURN）

ブラウザでネットワークをまたぐファイルとテキストの転送——ペアリングコードのセッション（その参加リンクを含む）——は、フォールバックではなく設計上 TURN サーバー経由で中継されます。制限の厳しい NAT やファイアウォールのため、アプリは最初からリレー経路を強制します。同一ネットワークのブラウザセッションには中継用資格情報が発行されず、直接接続します。CLI のファイルとテキスト転送は TURN を使わず、直接接続のみで、直接の経路が見つからなければ失敗します。

中継サーバーは暗号文のみを転送します。ファイルやメッセージを読むことはできず、エンドツーエンド暗号化が維持されます。
月間中継割り当ての管理と不正利用の防止のため、中継バイト数はアカウントごとに記録します——中継内容を検査することはなく、記録するのはバイト数のみです。
中継されたコンテンツを検査することはありません。

一時テキスト転送

ブラウザのテキストセッションは Web プロトコルを使用します。ピアは一時的な X25519 鍵交換を行い、ファイル転送鍵とは別のドメインで方向ごとに分離された AES-256-GCM サブ鍵を導出します。有効な UTF-8 メッセージはそれぞれ独立したフレームとして認証・暗号化されます。ネットワークをまたぐブラウザセッションは設計上 TURN を使用し、リレーは暗号文のみを運びメッセージ鍵を持ちません。高度な検証をオンにして SAS を帯域外で照合すれば、シグナリングの傍受も検出できます。

CLI テキストは、証明書をピン留めした TLS 1.3 上の別の直接接続専用プロトコルです。ブラウザの X25519/AES メッセージフレームや TURN は使わず、直接経路を確立できなければ失敗します。Relayium はメッセージ本文を保存しませんが、受信後はいずれのエンドポイントもテキストをコピー、記録、スクリーンショットその他の方法で保持できます。

双方が同時にオンラインである必要があります。Relayium はテキストのオフライン配信もサーバー側のメッセージ履歴も提供しません。
サーバーは接続に必要なメタデータを処理します。これには IP アドレス、ルーム所属、時刻、ブラウザセッションのデバイス名と在席状況、および該当する場合はペアリングコード作成に使われたアカウントとの関連付けが含まれます。
TURN セッションでは、割り当ての管理と不正利用防止のために中継バイト数を記録する場合がありますが、メッセージの平文を検査することはありません。

一時保存ダウンロードリンク——鍵はブラウザから出ない

オプションのダウンロードリンクモードは、受信者がオンラインでない場合のためのものです。ブラウザは何かがアップロードされる前にファイルを AES-256-GCM で暗号化し、復号鍵は URL フラグメント——# より後ろの部分——にのみ置かれます。ブラウザはこれをサーバーに送信しません。

サーバーが保存するのは暗号文と、クォータおよびクリーンアップのための暗号文サイズとタイムスタンプだけで、平文・ファイル名・鍵は決して保存しません。
完全なリンクを持つ人は誰でも復号できるため、リンクをファイルそのものと同様に扱い、信頼できる経路で共有してください。
リンクには有効期限（1 時間から最長 14 日、プランにより異なります）を設定するか、最初の完全なダウンロード後に消える設定にできます。

ファイル整合性（SHA-256）

機密性に加えて、各ファイルの整合性も検証されます。各チャンクには AES-GCM の認証タグが付き、受信側ではファイルごとの SHA-256 ハッシュがエンドツーエンドで照合されるため、破損・改ざんされたファイルは黙って受け入れられるのではなく検出されます。

Relayium が防げないこと

エンドツーエンド暗号化は、2 つの誠実なエンドポイント間の転送中のデータを保護します。設計上、次のものは防げません：

いずれかの端末側のデバイスやブラウザの侵害——マルウェア、悪意ある拡張機能、あるいは画面を覗き見る人。
サーバーが必然的に扱うメタデータ：セッション時刻、中継バイト数、そして（保存型ダウンロードリンクまたはペアリングコードのセッションでは）リンクやコードを作成したアカウント。
受信者がファイルやメッセージを受け取った後に保持、コピー、転送することを選ぶこと。
復号鍵がリンク内に含まれるため、信頼できない経路でダウンロードリンクを共有すること。

ブラウザ対応とその限界

Relayium は、HTTPS 経由で WebRTC が使える最新ブラウザで動作します。一部の機能はブラウザによって異なります：

デスクトップ版の Chrome と Edge は File System Access API を備えており、大きなファイルをディスクへ直接ストリーミングするため、実質的なメモリ上限はありません。
Firefox と Safari、そしてすべてのモバイルブラウザ（iOS ではどのブラウザも WebKit です）はこの API を持たず、リアルタイム受信の経路ではファイルをメモリ上で組み立てます。そのため、およそ 256 MB を超えるとアプリが事前に警告します——これは実測した上限ではなく、意図的に控えめに置いた見積もりです。その規模のファイルにはデスクトップ版の Chrome/Edge を使うか、ダウンロードリンクモードをご利用ください。後者のダウンロードページは service worker 経由でディスクへ流し込むこともできます。
WebRTC はセキュアコンテキスト（HTTPS）を必要とします。アプリは平文の HTTP では接続しません。

オープンソースと問題の報告

プロトコル設計とクライアント・サーバーの全コードは GitHub で公開されており、誰でも暗号方式を監査し、自分のサーバーを運用し、貢献できます。セキュリティ上の問題を見つけた場合は、公開の issue を作成するのではなく、リポジトリの GitHub 非公開脆弱性報告を通じて非公開でご報告ください。