技术白皮书

本白皮书描述了 PDF Pro 安全传输系统的架构——一种端到端加密文件传输机制，文件在上传前通过 AES-256-GCM 在客户端进行加密。服务器仅存储不透明的密文，在任何时候都无法解密、检查或读取文件内容。该系统支持两种密钥模式：自动生成的随机密钥（通过 URL 片段传输，该片段从不发送至服务器）或使用 PBKDF2 派生的口令密钥。在两种模式下，加密密钥仅存在于发送方和接收方的浏览器中。本文档详细介绍了密码学原语、数据流、威胁模型以及系统的已知局限性。术语说明：本系统不使用零知识证明（ZKP）。当我们说服务器对您的文件具有"零知识"时，我们的意思是——作为客户端加密的结果——服务器持有的始终是其无法解密的密文。

安全传输系统遵循严格的客户端-服务器分离原则，所有密码学操作均在浏览器中独立执行：

• 客户端（浏览器）：密钥派生、加密、解密、文件读取、文件重建。
• 服务器（Supabase 存储 + 无服务器函数）：存储加密数据块，管理元数据（过期时间、下载次数），执行访问策略。

服务器被有意设计为加密数据的"哑管道"。它不知晓加密密钥、口令或文件内容。这是通过架构强制实现的，而非仅仅依赖策略。

所有文件加密均使用 AES-256-GCM 认证加密算法，通过浏览器原生 Web Crypto API 调用。该算法同时提供机密性（数据不可读取）和完整性（数据不可被篡改而不被察觉）。

1.3.1 算法参数

1.3.2 加密实现

// 简化的加密流程（Web Crypto API）

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

// 从口令派生密钥（见第 1.4 节）
const key = await deriveKey(passphrase, salt);

// 加密文件
const ciphertext = await crypto.subtle.encrypt(
  { name: "AES-GCM", iv: iv },
  key,
  fileArrayBuffer
);

// 打包：[salt (16B)] + [iv (12B)] + [ciphertext + tag]
const blob = concatenate(salt, iv, ciphertext);

最终加密数据块是三个组件的拼接：16 字节的盐值（用于密钥派生）、12 字节的 IV（用于 AES-GCM），以及附带 16 字节 GCM 认证标签的密文。该数据块即为服务器接收并存储的内容。

安全传输支持两种互斥的密钥模式，发送方在创建传输时选择。

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) {
  // 将口令作为原始密钥材料导入
  const keyMaterial = await crypto.subtle.importKey(
    "raw",
    new TextEncoder().encode(passphrase),
    { name: "PBKDF2" },
    false,
    ["deriveKey"]
  );

  // 派生 AES-256-GCM 密钥
  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（600K 次迭代）从口令派生 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（600K 次迭代）从口令 + 盐值派生 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 的密码学的根本局限性。
• 无前向保密性。如果口令在加密数据块被删除之前的任何时间被泄露，存储的数据块副本可被解密。即读即焚和短过期时间可缓解此风险。
• 依赖浏览器安全模型。系统安全性取决于浏览器对 Web Crypto API 的实现及其内存隔离。被攻破的浏览器或恶意浏览器扩展程序可能破坏所有客户端保护。
• 量子计算。AES-256 被认为具有抗量子性（Grover 算法将有效安全性降低至 128 位，仍然不可行）。然而，基于 SHA-256 的 PBKDF2 并非专门针对后量子抗性设计。这不是近期关切，但在此注明以示完整。

本白皮书描述了 PDF Pro 隐私签名系统的架构——一种密码学文档签名机制，PDF 文档从不离开签名者的浏览器。该系统使用带 P-256 曲线的 ECDSA 和 SHA-256 哈希来生成分离式数字签名。只有文档哈希、密码学签名和公钥被传输至服务器。私钥在用户浏览器中生成、加密并存储在 IndexedDB 中，受 PBKDF2 密钥派生（600,000 次迭代）和 AES-256-GCM 加密保护。本文档详细介绍了完整的签名和验证架构、密钥管理模型、签名载荷模式、审计跟踪设计、威胁模型以及已知局限性。

隐私签名系统围绕一个基本约束设计：PDF 文档绝不能传输至服务器。这通过分离式签名模型在架构上强制执行。

• 客户端（浏览器）：密钥生成、密钥存储（在 IndexedDB 中加密）、文档哈希（SHA-256）、签名生成（ECDSA P-256）、签名验证。
• 服务器（Supabase）：存储公钥、签名记录（哈希 + 签名 + 元数据）、审计跟踪事件。从不接收 PDF 文档、私钥或密钥口令。

2.3.1 算法参数

2.3.2 签名流程

// 1. 哈希 PDF 文档（客户端）
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,   // 来自 IndexedDB 的 CryptoKey（已解密）
  hashBuffer
);

// 3. 向服务器发送：哈希 + 签名 + 公钥（而非 PDF）
await submitSignature({
  documentHash: hashHex,
  signature: base64Encode(signature),
  publicKey: exportedPublicKeyJWK
});

2.4.1 密钥生成

// 生成 ECDSA P-256 密钥对（Web Crypto API）
const keyPair = await crypto.subtle.generateKey(
  {
    name: "ECDSA",
    namedCurve: "P-256"
  },
  true,   // 可提取（加密 + 存储所需）
  ["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 格式，未加密 */ },
  "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 个字符）。
• 哈希的 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-of-previous-audit-event or null",
    "eventHash":         "sha256-of-this-record"
  }
}

签名验证是一个两阶段过程：客户端密码学验证，随后是服务器端交叉核验。

2.8.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 第二阶段：服务器端交叉核验

1. 服务器确认签名记录中的公钥已注册至已知用户（针对已认证签名）。
2. 服务器确认签名记录未被撤销。
3. 服务器确认审计跟踪完整性（哈希链验证）。
4. 服务器返回签名者的身份级别和注册状态。

2.8.3 验证结果

每个签名和验证事件都记录在防篡改审计跟踪中。事件通过哈希链接：每个事件包含前一事件的 SHA-256 哈希，形成类似区块链的仅追加链。

2.9.1 审计事件类型

2.9.2 哈希链结构

// 每个审计事件包含：
{
  "eventId":            "uuid-v4",
  "eventType":          "DOCUMENT_SIGNED",
  "timestamp":          "ISO-8601-UTC",
  "data":               { /* 事件特定载荷 */ },
  "previousEventHash": "sha256-of-previous-event-json",
  "eventHash":          "sha256-of-this-event-json-without-eventHash"
}

// 篡改检测：要验证链，请计算：
// SHA-256(JSON.stringify(不含 eventHash 字段的事件))
// 并确认其与 eventHash 匹配。
// 然后确认 previousEventHash 与前一事件的 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，只有合格电子签名在所有欧盟成员国具有与手写签名相当的法律效力。PDF Pro 签名充其量是高级电子签名，其法律地位取决于具体司法管辖区和使用场景。
• 不受 Adobe 信任。PDF Pro 签名不在 Adobe 批准信任列表（AATL）中。在 Adobe Acrobat 中打开经 PDF Pro 签名的文档时，签名在 Adobe 的 UI 中不会显示为"受信任"。验证必须通过 PDF Pro 的验证系统进行。
• 不是证书颁发机构。我们不颁发 X.509 证书。我们的公钥基础设施（PKI）是 PDF Pro 专有的，与政府机构或证书颁发机构使用的 PKI 系统不兼容。
• 不是公证。PDF Pro 签名不构成公证、附加认证或任何形式的政府认证文件鉴定。
• 无现实世界身份验证。我们通过 Supabase Auth 验证电子邮件地址，但我们不执行政府证件验证、生物特征验证或亲身身份证明。

2.12.1 PDF Pro 签名适用于什么

• 业务工作流 — 内部文件审批、团队签字确认、采购授权，前提是各方信任 PDF Pro 身份模型。
• 完整性验证 — 证明文档自特定时间点以来未被修改。
• 不可否认性（有限） — 证明特定私钥的持有者在特定时间签署了特定文档。不可否认性的强度取决于私钥保护程度以及公钥与身份的绑定方式。
• 审计合规 — 为内部合规要求提供文档签名事件的防篡改审计跟踪。
• 合同签署 — 在许多司法管辖区，根据 ESIGN（美国）、UETA（美国）和 eIDAS 第 25(1) 条（欧盟）等法律，电子签名（包括非合格签名）对大多数商业合同具有法律效力。