技術ホワイトペーパー

本ホワイトペーパーでは、PDF Proのセキュア転送システムのアーキテクチャについて説明します。このシステムはエンドツーエンド暗号化ファイル転送の仕組みであり、ファイルはアップロード前にAES-256-GCMを使用してクライアントサイドで暗号化されます。サーバーは不透明な暗号文のみを保存し、いかなる時点においてもファイルの内容を復号・検査・読み取る能力を持ちません。システムは2つの主要モードをサポートします。1つはURLフラグメントを介して転送される自動生成ランダム鍵（サーバーには送信されません）、もう1つはPBKDF2を使用したパスフレーズ派生鍵です。いずれのモードでも、暗号化鍵は送信者と受信者のブラウザ内にのみ存在します。本ドキュメントでは、暗号プリミティブ、データフロー、脅威モデル、およびシステムの正直な制限事項について詳述します。用語についての注記：本システムはゼロ知識証明（ZKP）を使用していません。「サーバーはあなたのファイルについてゼロ知識である」と述べる場合、これはクライアントサイド暗号化の結果として、サーバーは復号できない暗号文のみを保持することを意味します。

セキュア転送システムは厳格なクライアントとサーバーの分離に従っており、すべての暗号処理は専らブラウザ内で行われます：

• クライアント（ブラウザ）： 鍵導出、暗号化、復号、ファイル読み取り、ファイル再構築。
• サーバー（Supabase Storage + サーバーレス関数）： 暗号化されたブロブの保存、メタデータの管理（有効期限、ダウンロード数）、アクセスポリシーの実施。

サーバーは意図的に暗号化データの「ダムパイプ」として設計されています。暗号化鍵、パスフレーズ、ファイルの内容については一切の知識を持ちません。これはポリシーによるものではなく、アーキテクチャ的に強制されています。

すべてのファイル暗号化は、ブラウザネイティブの Web Crypto API を通じてアクセスされるAES-256-GCM認証付き暗号化アルゴリズムを使用します。これにより、機密性（データを読み取れない）と完全性（検出なしにデータを改ざんできない）の両方が提供されます。

1.3.1 アルゴリズムパラメータ

1.3.2 暗号化の実装

// Simplified encryption flow (Web Crypto API)

const iv = crypto.getRandomValues(new Uint8Array(12));
const salt = crypto.getRandomValues(new Uint8Array(16));

// Derive key from passphrase (see Section 1.4)
const key = await deriveKey(passphrase, salt);

// ファイルを暗号化する
const ciphertext = await crypto.subtle.encrypt(
  { name: "AES-GCM", iv: iv },
  key,
  fileArrayBuffer
);

// Package: [salt (16B)] + [iv (12B)] + [ciphertext + tag]
const blob = concatenate(salt, iv, ciphertext);

最終的な暗号化ブロブは3つの要素の連結です：16バイトのソルト（鍵導出に使用）、12バイトのIV（AES-GCMに使用）、および付加された16バイトのGCM認証タグを含む暗号文。このブロブがサーバーが受信・保存するものです。

セキュア転送は、相互に排他的な2つの鍵モードをサポートします。モードは転送作成時に送信者が選択します。

1.4.1 モードA — 自動生成鍵（デフォルト）

デフォルトモードでは、パスフレーズは関与しません。ブラウザは直接、暗号学的にランダムな256ビットのAES鍵を生成します：

• ブラウザは crypto.getRandomValues() と crypto.subtle.generateKey() を使用してランダムな256ビットのAES-GCM鍵を生成します。
• 鍵は生バイトとしてエクスポートされ、URLフラグメント（#）に配置されます。
• HTTP仕様により、URLフラグメントはサーバーに送信されません — ブラウザによってのみ処理されます。
• 送信者はフラグメントを含む完全なURLを、好みのチャンネル（例：メッセージアプリ、メール）を通じて受信者と共有します。
• 受信者のブラウザはURLフラグメントから鍵を抽出し、ファイルの復号に使用します。

1.4.2 モードB — パスフレーズ保護転送

送信者がパスフレーズの設定を選択した場合、PBKDF2を使用してそのパスフレーズから鍵が導出されます：

• ユーザーがパスフレーズを提供します。
• パスフレーズを使用してPBKDF2-SHA256でAES-256鍵を導出します。
• パラメータ：600,000回の反復、ランダムな16バイトのソルト。
• 導出された鍵でファイルを暗号化します。
• ソルトは暗号文とともに保存されます（暗号化ブロブの先頭に付加）。
• パスフレーズはアウトオブバンドで共有されます（リンクとは別に）。
• パスフレーズの回復は不可能です — サーバーもPDF Proも忘れたパスフレーズを回復できません。

1.4.3 PBKDF2パラメータ（モードB）

1.4.4 鍵導出の実装（モードB）

async function deriveKey(passphrase, salt) {
  // Import passphrase as raw key material
  const keyMaterial = await crypto.subtle.importKey(
    "raw",
    new TextEncoder().encode(passphrase),
    { name: "PBKDF2" },
    false,
    ["deriveKey"]
  );

  // Derive AES-256-GCM key
  return crypto.subtle.deriveKey(
    {
      name: "PBKDF2",
      salt: salt,
      iterations: 600000,
      hash: "SHA-256"
    },
    keyMaterial,
    { name: "AES-GCM", length: 256 },
    false,
    ["encrypt", "decrypt"]
  );
}

セキュア転送の完全なライフサイクルは次のパスをたどります：

1.5.1 送信（アップロード） — モードA（自動生成鍵）

1. 送信者がブラウザでファイルを選択します。
2. ブラウザは crypto.getRandomValues() を使用して、ランダムな256ビットのAES-GCM鍵とランダムな12バイトのIVを生成します。
3. ブラウザはAES-256-GCMを使用してファイルを暗号化し、暗号文＋認証タグを生成します。
4. ブラウザは[IV | 暗号文＋タグ]を単一のブロブに連結します。
5. ブラウザはHTTPS経由で暗号化ブロブをサーバーにアップロードします。
6. サーバーはブロブをSupabase Storageに保存し、メタデータレコード（転送ID、有効期限、ダウンロード制限、ファイル名、ファイルサイズ）を作成します。
7. サーバーは転送URLを返します。ブラウザはエクスポートされた鍵をURLフラグメント（#）に付加します。
8. 送信者はフラグメントを含む完全なURLを受信者と共有します。

1.5.2 送信（アップロード） — モードB（パスフレーズ）

1. 送信者はブラウザでファイルを選択し、パスフレーズを入力します。
2. ブラウザは crypto.getRandomValues() を使用して、ランダムな16バイトのソルトと12バイトのIVを生成します。
3. ブラウザはPBKDF2（60万回の反復）を使用してパスフレーズからAES-256鍵を導出します。
4. ブラウザはAES-256-GCMを使用してファイルを暗号化し、暗号文＋認証タグを生成します。
5. ブラウザは[ソルト | IV | 暗号文＋タグ]を単一のブロブに連結します。
6. ブラウザはHTTPS経由で暗号化ブロブをサーバーにアップロードします。
7. サーバーはブロブをSupabase Storageに保存し、メタデータレコード（転送ID、有効期限、ダウンロード制限、ファイル名、ファイルサイズ）を作成します。
8. サーバーは転送IDを含む転送URLを返します。
9. 送信者は転送URLとパスフレーズを別々のチャンネルを通じて受信者と共有します。

1.5.3 受信（ダウンロード） — モードA

1. 受信者はフラグメントに鍵が含まれた完全な転送URLを開きます。
2. ブラウザはURLフラグメントからAES鍵を抽出します（サーバーには送信されません）。
3. ブラウザはHTTPS経由でサーバーから暗号化ブロブをダウンロードします。
4. ブラウザはブロブからIV（最初の12バイト）を抽出します。
5. ブラウザは抽出された鍵とIVを使用してAES-256-GCMで暗号文を復号します。
6. 復号が成功した場合（GCMタグが検証される）、平文ファイルがユーザーに提示されます。
7. サーバーはダウンロードカウンターを更新し、読み取り後消去が有効な場合はブロブを削除します。

1.5.4 受信（ダウンロード） — モードB

1. 受信者は転送URLを開き、ブラウザでパスフレーズを入力します。
2. ブラウザはHTTPS経由でサーバーから暗号化ブロブをダウンロードします。
3. ブラウザはブロブからソルト（最初の16バイト）とIV（次の12バイト）を抽出します。
4. ブラウザはPBKDF2（60万回の反復）を使用してパスフレーズ＋ソルトからAES-256鍵を導出します。
5. ブラウザは導出された鍵とIVを使用してAES-256-GCMで暗号文を復号します。
6. 復号が成功した場合（GCMタグが検証される）、平文ファイルがユーザーに提示されます。
7. 復号が失敗した場合（誤ったパスフレーズ＝誤った鍵＝無効なGCMタグ）、エラーが表示されます。
8. サーバーはダウンロードカウンターを更新し、読み取り後消去が有効な場合はブロブを削除します。

すべてのセキュア転送は設計上、一時的なものです。永続的なストレージのオプションはありません。

1.7.1 有効期限オプション

1.7.2 削除の保証

転送が期限切れになるか読み取り後に消去されると、暗号化ブロブはSupabase Storageから完全に削除されます。メタデータレコードは、完全に消去される前に30日間ソフト削除状態で保持されます（不正使用調査のため）。メタデータレコードには、暗号化鍵、パスフレーズ、またはファイルの再構築に使用できる情報は含まれていません。

1.8.1 前提条件

• 信頼されたブラウザランタイム（悪意のある拡張機能なし）
• リンク／パスフレーズ共有のための安全なチャンネル
• HTTPSの終端が信頼されている
• 受信者のデバイスが侵害されていない
• 画面キャプチャの防止なし

1.8.2 対象外

• エンドポイントデバイスのマルウェア
• ソーシャルエンジニアリング／フィッシング攻撃
• 受信者による画面キャプチャ
• 侵害されたブラウザ拡張機能
• 量子コンピューティング攻撃（将来の検討事項）

• パスフレーズの強度はユーザーが制御します。 UIで最小長を強制することはできますが、ユーザーが弱いパスフレーズを選ぶことを防ぐことはできません。暗号化のセキュリティはパスフレーズのエントロピーに直接比例します。
• パスフレーズの伝達はアウトオブバンドです。 パスフレーズを共有するための安全なチャンネルは提供していません。パスフレーズが安全でないチャンネル（例：転送URLと一緒の暗号化されていないメール）で共有された場合、セキュリティモデルが弱まります。
• ファイルメタデータは暗号化されていません。 元のファイル名とファイルサイズはサーバー上に平文で保存されます。これにより、ファイルの内容が暗号化されたままであっても、転送されたファイルの種類と大まかな性質が明らかになります。
• クライアントサイドコードへの信頼。 ユーザーは当社のCDNが提供するJavaScriptが正しく、改ざんされていないコードであることを信頼しなければなりません。侵害されたCDNやDNSハイジャックにより、悪意のあるJavaScriptが提供される可能性があります。これはすべてのウェブベース暗号化の根本的な制限です。
• 前方秘匿性がありません。 暗号化ブロブが削除される前にいずれかの時点でパスフレーズが侵害された場合、保存されたブロブのコピーを復号できます。読み取り後消去と短い有効期限がこのリスクを軽減します。
• ブラウザセキュリティモデルへの依存。 システムのセキュリティは、ブラウザのWeb Crypto API実装とそのメモリ分離に依存します。侵害されたブラウザや悪意のあるブラウザ拡張機能は、すべてのクライアントサイド保護を損なう可能性があります。
• 量子コンピューティング。 AES-256は量子耐性があると考えられています（Groverのアルゴリズムにより有効なセキュリティは128ビットに低下しますが、依然として実行不可能です）。ただし、SHA-256を使用したPBKDF2はポスト量子耐性のために特別に設計されていません。これは近い将来の懸念ではありませんが、完全を期すために記載します。

本ホワイトペーパーでは、PDF ProのPrivacy Signatureシステムのアーキテクチャについて説明します。このシステムは、PDFドキュメントが署名者のブラウザから出ることのない暗号文書署名の仕組みです。システムはP-256曲線とSHA-256ハッシュを使用したECDSAを使用して、デタッチされたデジタル署名を生成します。ドキュメントハッシュ、暗号署名、公開鍵のみがサーバーに送信されます。秘密鍵はIndexedDBを使用してユーザーのブラウザ内でのみ生成・暗号化・保存され、PBKDF2鍵導出（600,000回の反復）とAES-256-GCM暗号化によって保護されます。本ドキュメントでは、完全な署名と検証のアーキテクチャ、鍵管理モデル、署名済みペイロードスキーマ、監査証跡設計、脅威モデル、および正直な制限事項について詳述します。

Privacy Signatureシステムは、基本的な制約を中心に設計されています：PDFドキュメントはサーバーに送信されてはなりません。これはデタッチ署名モデルによってアーキテクチャ的に強制されています。

• クライアント（ブラウザ）： 鍵生成、鍵保存（IndexedDBに暗号化して保存）、ドキュメントハッシュ（SHA-256）、署名生成（ECDSA P-256）、署名検証。
• サーバー（Supabase）： 公開鍵、署名レコード（ハッシュ＋署名＋メタデータ）、監査証跡イベントを保存。PDFドキュメント、秘密鍵、鍵のパスフレーズは決して受信しません。

2.3.1 アルゴリズムパラメータ

2.3.2 署名フロー

// 1. Hash the PDF document (client-side)
const fileBuffer = await file.arrayBuffer();
const hashBuffer = await crypto.subtle.digest("SHA-256", fileBuffer);
const hashHex = Array.from(new Uint8Array(hashBuffer))
  .map(b => b.toString(16).padStart(2, '0')).join('');

// 2. 秘密鍵でハッシュに署名する（クライアントサイド）
const signature = await crypto.subtle.sign(
  { name: "ECDSA", hash: "SHA-256" },
  privateKey,   // CryptoKey from IndexedDB (decrypted)
  hashBuffer
);

// 3. サーバーに送信: ハッシュ + 署名 + 公開鍵（PDFは送信しない）
await submitSignature({
  documentHash: hashHex,
  signature: base64Encode(signature),
  publicKey: exportedPublicKeyJWK
});

2.4.1 鍵生成

// Generate ECDSA P-256 key pair (Web Crypto API)
const keyPair = await crypto.subtle.generateKey(
  {
    name: "ECDSA",
    namedCurve: "P-256"
  },
  true,   // extractable (needed for encryption + storage)
  ["sign", "verify"]
);

// サーバー登録用にJWK形式で公開鍵をエクスポートする
const publicKeyJWK = await crypto.subtle.exportKey("jwk", keyPair.publicKey);

// 暗号化ストレージ用にJWK形式で秘密鍵をエクスポートする
const privateKeyJWK = await crypto.subtle.exportKey("jwk", keyPair.privateKey);

永続的な秘密鍵は平文で保存されることはありません。IndexedDBへの書き込み前に、秘密鍵（JWK JSONとしてエクスポート）はセキュア転送と同じパターンを使用して暗号化されます：

2.5.1 保護パラメータ

2.5.2 ストレージスキーマ

// 暗号化署名キーのIndexedDBレコード構造
{
  "keyId":       "uuid-v4-unique-identifier",
  "publicKey":   { /* JWK format, unencrypted */ },
  "encryptedPrivateKey": {
    "salt":       "base64-encoded-16-bytes",
    "iv":         "base64-encoded-12-bytes",
    "ciphertext": "base64-encoded-aes-gcm-ciphertext"
  },
  "algorithm":   "ECDSA",
  "curve":       "P-256",
  "createdAt":   "2026-04-16T00:00:00.000Z",
  "userId":      "supabase-auth-user-id"
}

PDF Proはデタッチ署名モデルを使用しています。これは署名がドキュメントとは別に保存されることを意味します。これが重要なプライバシーメカニズムです：ドキュメントは署名者のデバイスから出ることはありません。

2.6.1 サーバーに送信されるもの

• PDFのSHA-256ハッシュ（32バイト、64文字の16進数エンコード）。
• ハッシュに対するECDSA署名（64バイト、base64エンコード）。
• 署名者の公開鍵（JWKフォーマット）。
• メタデータ：署名者の表示名、署名者のメール（認証済みの場合）、タイムスタンプ、署名ID。

2.6.2 サーバーに送信されないもの

• PDFドキュメント本体 — 決して送信されません。
• 秘密鍵 — ブラウザから出ることはありません。
• 署名パスフレーズ — ブラウザから出ることはありません。
• PDFのページコンテンツ、テキスト、または画像。

以下のJSONスキーマは、サーバーに保存される完全な署名レコードを定義します：

{
  "schemaVersion":  "1.0",
  "signatureId":    "uuid-v4",
  "documentHash":   "sha256-hex-64-chars",
  "hashAlgorithm":  "SHA-256",
  "signature":      "base64-encoded-ecdsa-signature",
  "signatureAlgorithm": "ECDSA",
  "curve":          "P-256",
  "publicKey": {
    "kty": "EC",
    "crv": "P-256",
    "x":   "base64url-encoded-x-coordinate",
    "y":   "base64url-encoded-y-coordinate"
  },
  "signer": {
    "identityLevel": "authenticated | self-asserted",
    "displayName":   "string or null",
    "email":         "string or null",
    "userId":        "supabase-uid or null"
  },
  "timestamp":      "ISO-8601-UTC",
  "metadata": {
    "fileName":     "original-file-name.pdf",
    "fileSize":     123456,
    "pageCount":    12,
    "clientVersion": "2.0.0",
    "userAgent":    "browser-user-agent-string"
  },
  "auditChain": {
    "previousEventHash": 「前の監査イベントのsha256、または null」,
    "eventHash":         「このレコードのsha256」
  }
}

署名検証は2フェーズのプロセスです：クライアントサイドの暗号検証に続いて、サーバーサイドのクロスチェックが行われます。

2.8.1 フェーズ1：クライアントサイドの暗号検証

1. ユーザーがブラウザにPDFを読み込みます。
2. ブラウザが読み込まれたPDFのSHA-256ハッシュを計算します。
3. ブラウザがこのハッシュに一致する署名レコードのサーバーに問い合わせます。
4. 返された各署名レコードについて、ブラウザはECDSA検証を実行します：

   const isValid = await crypto.subtle.verify(
     { name: "ECDSA", hash: "SHA-256" },
     importedPublicKey,
     signatureBuffer,
     hashBuffer
   );

5. isValid === true の場合、署名は暗号学的に有効です：ドキュメントは署名以降改ざんされておらず、署名は対応する秘密鍵の保有者によって生成されました。

2.8.2 フェーズ2：サーバーサイドのクロスチェック

1. サーバーは署名レコードの公開鍵が既知のユーザーに登録されていることを確認します（認証済み署名の場合）。
2. サーバーは署名レコードが失効していないことを確認します。
3. サーバーは監査証跡の整合性を確認します（ハッシュチェーン検証）。
4. サーバーは署名者のアイデンティティレベルと登録ステータスを返します。

2.8.3 検証結果

すべての署名および検証イベントは、改ざん防止の監査証跡に記録されます。イベントはハッシュチェーン化されています：各イベントには前のイベントのSHA-256ハッシュが含まれており、ブロックチェーンに似た追記専用のチェーンを形成します。

2.9.1 監査イベントの種類

2.9.2 ハッシュチェーン構造

// Each audit event includes:
{
  "eventId":            "uuid-v4",
  "eventType":          "DOCUMENT_SIGNED",
  "timestamp":          "ISO-8601-UTC",
  "data":               { /* event-specific payload */ },
  "previousEventHash": "sha256-of-previous-event-json",
  "eventHash":          「eventHashを除くこのイベントJSONのsha256」
}

// 改ざん検出: チェーンを検証するには次を計算する:
// SHA-256(JSON.stringify(event without eventHash field))
// and confirm it matches eventHash.
// Then confirm previousEventHash matches the prior event's eventHash.

チェーン内のいずれかのイベントが変更されると、それ以降のすべてのハッシュリンクが壊れ、改ざんが即座に検出可能になります。これにより、監査証跡の整合性が強力に保証されます。

注記： 製品UIでは、「self_asserted」は「自己申告アイデンティティ」または「ゲスト署名」として表示される場合があります。「authenticated」は「認証済みアカウント」として表示される場合があります。これらは同じ基礎アイデンティティレベルの表示ラベルです。

2.11.1 前提条件

• 信頼されたブラウザランタイム
• Web Crypto APIの実装が正確
• IndexedDBが他のオリジンからアクセスできない
• ユーザーがパスフレーズを保護している
• サーバーコードが公開された動作と一致している

2.11.2 対象外

• エンドポイントデバイスのマルウェア
• ソーシャルエンジニアリング／フィッシング攻撃
• 受信者による画面キャプチャ
• 侵害されたブラウザ拡張機能
• 量子コンピューティング攻撃（将来の検討事項）

• 適格電子署名（QES）ではありません。 PDF Proの署名は、適格電子署名に関するEU規則910/2014（eIDAS）の要件を満たしていません。当社は適格トラストサービスプロバイダー（QTSP）ではなく、署名鍵は適格署名作成デバイス（QSCD）上で生成されていません。
• eIDAS適格ではありません。 eIDASの下では、適格電子署名のみがすべてのEU加盟国で手書き署名と同等の法的効力を持ちます。PDF Proの署名は精々高度な電子署名であり、その法的効力は特定の管轄区と使用ケースに依存します。
• Adobe信頼済みではありません。 PDF Proの署名はAdobe Approved Trust List（AATL）に掲載されていません。Adobe AcrobatでPDF Pro署名済みドキュメントを開くと、AdobeのUIでは署名が「信頼済み」として表示されません。検証はPDF Proの検証システムを通じて行う必要があります。
• 認証局ではありません。 当社はX.509証明書を発行しません。当社の公開鍵基盤はPDF Pro独自のものであり、政府機関や認証局が使用するPKIシステムとの相互運用性はありません。
• 公証ではありません。 PDF Proの署名は、公証、アポスティーユ、または政府認定の文書認証には該当しません。
• 実世界のアイデンティティ確認なし。 Supabase Authを通じてメールアドレスを確認しますが、政府ID確認、生体認証確認、または対面アイデンティティ証明は行いません。

2.12.1 PDF Pro署名が適しているもの

• ビジネスワークフロー — PDF Proアイデンティティモデルを信頼する当事者間での、社内文書承認、チームサインオフ、調達承認。
• 整合性確認 — 特定の時点からドキュメントが変更されていないことの証明。
• 否認防止（限定的） — 特定の秘密鍵の保有者が特定の時点に特定のドキュメントに署名したことの証明。否認防止の強度は、秘密鍵の保護状態とアイデンティティへの公開鍵のバインド方法に依存します。
• 監査コンプライアンス — 内部コンプライアンス要件のためのドキュメント署名イベントの改ざん防止監査証跡の提供。
• 契約署名 — 多くの管轄区では、ESIGN（米国）、UETA（米国）、およびeIDAS第25条第1項（EU）などの法律に基づき、電子署名（非適格なものを含む）がほとんどの商業契約に法的に有効です。