セキュリティホワイトペーパー

RocketShareがゼロ知識暗号化でファイルを保護する方法の技術的詳細

本文書は、RocketShareがどのようにデータを保護しているかについての包括的な技術概要を提供します。セキュリティ専門家、コンプライアンス担当者、および当社の暗号化の仕組みを正確に理解したい方を対象としています。

1. エグゼクティブサマリー

RocketShareは、ゼロ知識暗号化を採用したファイル共有プラットフォームです。ファイルはアップロード前にクライアント側でAES-256-GCMを使用して暗号化され、暗号化キーはURLフラグメント(ブラウザがサーバーに送信しないURLの一部)にのみ埋め込まれます。このアーキテクチャにより、RocketShareの運営者は、合法的な傍受要請を含むいかなる状況下でも、ユーザーファイルにアクセス、読取、復号化することができません。

主要な特性:

  • ゼロ知識アーキテクチャ — サーバーは復号化キーを一切保持しない
  • エンドツーエンド暗号化 — ファイルは送信者のデバイスを離れる前に暗号化され、受信者のデバイスでのみ復号化される
  • サーバー側でのキー保存なし — キーは共有リンクのURLフラグメント内にのみ存在する
  • 自動有効期限と削除 — ファイルは有効期限後に完全に削除される

2. 脅威モデル

保護対象

  • サーバー侵害 — 攻撃者が当社サーバーへの完全なアクセス権を取得した場合でも、保存されたファイルは転送ごとのキーなしでは暗号化されたまま読み取り不可能
  • ネットワーク傍受 — TLS 1.3が転送中のデータを保護し、URLフラグメント内の暗号化キーはネットワーク経由で送信されない
  • 内部脅威 — RocketShareの運営者は、ポリシーではなく設計により、ファイルの内容に一切アクセスできない
  • 合法的傍受 — 当社はキーを保持していないため復号化要請に応じることができず、暗号化されたブロブとメタデータのみを提供可能

脅威モデルの対象外

  • 送信者または受信者のデバイスの侵害 — マルウェアがユーザーのブラウザにアクセスできる場合、キーや平文ファイルを傍受される可能性がある
  • 共有リンクの傍受 — 完全な共有リンク(URLフラグメントを含む)を入手した者は誰でもファイルを復号化できるため、ユーザーはリンクを安全に共有する必要がある
  • ブラウザの脆弱性 — Web Crypto APIはブラウザが提供するため、ブラウザレベルのエクスプロイトは当社の制御外

3. 暗号化の実装

アルゴリズム

すべてのファイル暗号化にはAES-256-GCM(Galois/Counter Mode)が使用されます。これは対称認証暗号化アルゴリズムです。GCMは機密性と完全性の両方を提供し、暗号文への改ざんは復号化時に検出されます。

キー生成

暗号化キーは、オペレーティングシステムの暗号学的に安全な疑似乱数生成器(CSPRNG)に基づくブラウザのWeb Crypto API(crypto.subtle.generateKey)を使用してクライアント側で生成されます。

  • キーサイズ: 256ビット
  • ソース: Web Crypto API(crypto.subtle.generateKey)、OSレベルのCSPRNGに基づく
  • スコープ: 転送(ファイルまたはバンドル)ごとに1つの一意のキー

暗号化プロセス

  1. ユーザーがアップロード用のファイルを選択
  2. crypto.subtle.generateKey()を使用して256ビットAESキーを生成
  3. 暗号化操作ごとに一意の96ビット初期化ベクトル(IV)を生成
  4. Web Crypto APIを使用してブラウザ内でAES-256-GCMによりファイルを暗号化
  5. 暗号化された暗号文をサーバーにアップロード
  6. 生のキーマテリアルをBase64urlエンコードし、URLフラグメント(#<base64url-key>)に配置

ストリーミング暗号化

大きなファイルの場合、RocketShareはストリーミング暗号化アプローチを使用します。ファイルはチャンクで処理されメモリ使用量を最小化し、利用可能なRAMを超えるファイルの暗号化とアップロードを可能にします。

各チャンクは独自のランダム生成された96ビットIV(crypto.getRandomValues)で暗号化され、ファイルの内容が繰り返される場合でも各チャンクで一意の暗号文を保証します。

4. キー管理

URLフラグメントアプローチ

復号化キーはURLフラグメント(#以降の部分)に埋め込まれます。これがシステムの重要なセキュリティプロパティです:

  • ブラウザはURLフラグメントをサーバーに送信しない — HTTPリクエストでサーバーに送信されない(RFC 3986、セクション3.5)
  • フラグメントは完全にクライアント側に留まる — ブラウザのアドレスバー、履歴、ユーザーが共有する際
  • サーバーはパスとクエリパラメータのみを受信し、#...のキー部分は受信しない

キーのライフサイクル

  1. 生成 — CSPRNGを使用して送信者のブラウザで作成
  2. 使用 — クライアント側の暗号化に即座に使用
  3. 埋め込み — 共有リンクのURLフラグメントに配置
  4. 送信 — ユーザーが選択した安全なチャネル(メール、メッセンジャーなど)経由でリンクを共有
  5. 復号化 — 受信者のブラウザがフラグメントを読み取りファイルを復号化
  6. 保存なし — キーはサーバーに保存されず、共有リンク内にのみ存在

サーバーが保存するもの

サーバーは以下のみを保存します:

  • 暗号化されたファイルブロブ(暗号文)
  • 転送メタデータ: ファイル名、ファイルサイズ、MIMEタイプ、有効期限
  • 転送設定: ダウンロード制限、パスワード保護ハッシュ(有効な場合)
  • アカウントレベルデータ: メール、認証トークン(ファイル暗号化とは無関係)

サーバーは決して保存しない: 暗号化キー、平文ファイルの内容、キーの導出に使用できるデータ。

5. ファイルのライフサイクル

アップロード

  1. ユーザーがファイルを選択 → 暗号化キーがクライアント側で生成
  2. ブラウザ内でAES-256-GCMによりファイルを暗号化
  3. TLS 1.3経由で暗号化されたブロブをサーバーにアップロード
  4. サーバーが暗号文+メタデータを保存し、転送IDを返す
  5. 共有リンクを構築: https://rocketshare.app/d/{id}#{base64url-key}

保存

  • 暗号化されたファイルは**EU(アムステルダム)**でホストされているS3互換オブジェクトストレージに保存
  • ファイルは不透明な暗号化ブロブとして保存 — ストレージプロバイダーは読み取れない
  • メタデータはデータベースボリュームの保存時暗号化を使用してPostgreSQLに保存

ダウンロード

  1. 受信者が共有リンクを開く
  2. ブラウザがURLフラグメントからキーを抽出(サーバーには送信されない)
  3. サーバーから暗号化されたブロブをダウンロード
  4. 復号化は受信者のブラウザ内で完全に実行
  5. 平文ファイルがユーザーにダウンロード用に提示される

有効期限と削除

  • 転送には設定可能な有効期限がある(プランに応じて3日から90日)
  • 有効期限後、スケジュールされたクリーンアップタスクがオブジェクトストレージから暗号化されたブロブを完全に削除し、データベースからファイルレコードを削除
  • 転送メタデータレコード(ファイル名、サイズ、タイムスタンプ)は会計および監査目的で期限切れ状態で保持されるが、すべての暗号化されたファイルデータは不可逆的に削除される
  • 期限切れファイルデータのバックアップは保持されない

6. インフラストラクチャ

ホスティング

  • アプリケーション: Cloudflare Workers(エッジコンピュート)にデプロイ
  • データベース: PostgreSQL、EUでホスト
  • オブジェクトストレージ: S3互換、EU(アムステルダム)リージョン
  • キャッシュ: Cloudflare KV(キーバリューストア)、セッションとレート制限データのみに使用 — ファイルコンテンツには使用しない
  • CDN: 静的アセットとエッジルーティング用のCloudflareグローバルネットワーク

データレジデンシー

すべてのファイルストレージとデータベースサーバーは欧州連合内に配置されています。ファイルデータをEU外に複製することはありません。

ネットワークセキュリティ

  • TLS 1.3 — すべての接続(HTTPおよびデータベース)で強制
  • HSTS — プリロード付き、ブラウザに常にHTTPSを使用するよう指示
  • HTTPセキュリティヘッダー — CSP、X-Frame-Options、X-Content-Type-Options、Referrer-Policy、Permissions-Policy
  • 混合コンテンツなし — すべてのリソースをHTTPS経由でロード

7. 認証とアクセス制御

ユーザー認証

  • メール/パスワード — パスワードはscryptでハッシュ化(N=16384、r=16、p=1)、最小8文字の長さを強制
  • OAuth — 業界標準のOAuth 2.0 / OpenID Connect経由でGoogleおよびMicrosoft SSOを使用
  • セッション管理 — 適切なSameSite属性を持つ安全なHTTP-onlyクッキー

転送アクセス制御

  • リンクベースアクセス — 完全な共有リンクを持つ者は誰でも復号化可能(キーはURL内にある)
  • オプションのパスワード保護 — 転送に追加のパスワードを要求可能。暗号化されたブロブを配信する前にパスワードハッシュがサーバー側で検証される
  • ダウンロード制限 — リンクが無効化されるまでの最大ダウンロード数を設定可能
  • 有効期限 — 暗号化されたファイルデータが完全に削除される自動時間ベース有効期限

8. データ最小化と保持

最小データの原則

サービスの運営に必要なものだけを収集します:

  • アカウントデータ: メールアドレス、名前(OAuth経由で提供された場合)、ハッシュ化されたパスワード
  • 転送メタデータ: ファイル名、サイズ、MIMEタイプ、タイムスタンプ、有効期限
  • 使用状況データ: 転送数と使用されたストレージ(プラン執行用)
  • 分析: PostHog経由の匿名化された使用パターン(EUホスト、プライバシー重視の設定)

収集しないもの

  • ファイルの内容(暗号化されたブロブにアクセスできない)
  • 暗号化キー
  • 長期保存されるIPアドレス(アクセスログは一時的)
  • 閲覧履歴またはクロスサイトトラッキングデータ

保持

  • 転送: 暗号化されたファイルデータは有効期限時に自動削除。転送メタデータは期限切れ状態で保持
  • アカウントデータ: アカウントがアクティブな間保持。アカウント削除要求時に削除
  • アクセスログ: 一時的で、リクエストのライフサイクルを超えて保持されない

9. インシデント対応

セキュリティインシデントの場合:

  1. 封じ込め — 影響を受けたシステムを即座に隔離
  2. 評価 — 範囲と影響を判断。ゼロ知識アーキテクチャのおかげで、サーバー侵害はファイルの内容を露出しない
  3. 通知 — GDPRで要求される通り、影響を受けたユーザーに72時間以内に通知
  4. 修復 — 根本原因を修正し、防御を改善
  5. 開示 — インシデントと当社の対応を公開

セキュリティ問題は、当社の責任ある開示ポリシーを通じて報告できます。

10. 制限事項と透明性

当社は、セキュリティアーキテクチャが何を保護し何を保護しないかについて透明性を保つことを信じています:

  • 紛失したリンクは復元できない — ユーザーが共有リンク(URLフラグメントを含む)を紛失した場合、暗号化されたファイルは復号化できません。当社はキーを持っていません。
  • リンクのセキュリティはユーザーの責任 — 共有リンクは唯一のアクセス認証情報です。傍受された場合(例: 安全でないチャネル経由で送信)、傍受者はファイルを復号化できます。
  • nonceベースのスクリプトポリシーを持つCSP — strict-dynamicとnonceベースのスクリプトソースを使用したContent Security Policyを使用しており、これはSSRアプリケーションに推奨されるアプローチです。Tailwind CSSのため、インラインスタイルには依然としてunsafe-inlineが必要です。
  • ブラウザの信頼 — 当社の暗号化はWeb Crypto APIに依存しています。ブラウザが侵害された場合、すべてが無効になります。
  • メタデータの可視性 — ファイルの内容は暗号化されていますが、ファイル名、サイズ、タイムスタンプは運用上の目的でサーバーから見えます。

本ホワイトペーパーは2026年2月現在のものです。セキュリティアーキテクチャが変更された場合、この文書を更新します。ご質問はお問い合わせください。