构建透明密钥服务器：可审计公钥基础设施的工程实现

在公钥密码学中，密钥分发一直是安全链中最薄弱的环节。传统密钥服务器（如 SKS 网络）因垃圾邮件攻击而崩溃，而集中式密钥服务器虽然解决了可用性问题，却引入了单点信任风险。恶意或受攻击的密钥服务器可以悄无声息地向特定受害者提供虚假公钥，这种攻击几乎无法被检测。

透明日志（Transparency Log，简称 tlog）技术为这一困境提供了工程解决方案。Filippo Valsorda 在《构建透明密钥服务器》一文中展示了如何通过不到 500 行代码，将传统密钥服务器转变为具备可审计性、隐私保护和防篡改能力的透明系统。

透明日志的核心原理

透明日志本质上是一个追加式、全局一致的条目列表，每个条目都附带高效的密码学包含证明和一致性证明。客户端在接收条目前验证包含证明，确保日志操作者必须永久且公开地为该条目负责，无法隐藏或否认。

这种机制的核心优势在于：它允许日志操作者用声誉换取时间。操作者将条目记录在透明日志中，而客户端可以信任，只要有任何人（监控者）最终检查日志的真实性，任何不当行为都会被发现。这在实际工程中创造了一个中间地带：既不需要像 Web of Trust 那样不切实际的本地验证，也不像集中式 X.509 PKI 那样完全信任第三方。

从工程角度看，透明日志证明可以视为一种 "增强型签名"—— 使用日志公钥验证，就像验证 Ed25519 或 RSA 签名一样。这种抽象使得透明日志可以部署在任何能够部署常规数字签名的场景中。

隐私保护：可验证随机函数（VRF）

透明日志的一个明显问题是公开所有用户的电子邮件地址。虽然这对于 Go 校验和数据库中的模块名称是可以接受的，但对于密钥服务器来说，允许枚举电子邮件地址在隐私和防垃圾邮件方面是不可接受的。

简单的哈希解决方案仍然允许离线暴力破解攻击。正确的工具是可验证随机函数（VRF）。VRF 可以看作是一种带有私钥和公钥的哈希：只有持有私钥的人才能生成哈希值，但任何人都可以使用公钥验证这是正确且唯一的哈希值。

在实现中，密钥服务器不在日志条目中包含电子邮件地址，而是包含 VRF 哈希。服务器保存 VRF 证明在数据库中，并在透明日志证明的额外数据字段中包含 VRF 证明，使证明自包含。

客户端 CLI 从透明日志证明的额外数据中提取 VRF 哈希，并验证它是对应电子邮件地址的正确哈希。这种设计恢复了原始状态：枚举需要暴力破解在线、速率受限的 API，而不是在透明日志中拥有完整的电子邮件地址列表（或可以离线暴力破解的哈希值）。

VRF 还有进一步的好处：如果用户请求从服务中删除，虽然无法从透明日志中删除他们的条目，但可以停止从查找和监控 API 提供其电子邮件地址的 VRF。这使得无法获取该用户的密钥历史记录，甚至无法检查他们是否曾使用过密钥服务器，但不影响其他用户的监控。

防污染机制：哈希保护

由于无法从透明日志中删除条目，存在一个边际风险：攻击者可能通过将不当消息伪装成公钥插入日志中。虽然公钥必须是 Bech32 编码且较短，攻击者无法有效嵌入图像或恶意软件，但通过哈希机制可以轻松中和这种风险。

实现方案是：不在透明日志条目中包含公钥本身，而是包含其哈希值，将原始公钥保存在数据库的新表中，并通过监控 API 提供服务。关键工程细节是：必须在将条目添加到透明日志之前将原始密钥持久化到数据库中。丢失原始密钥将等同于拒绝向监控者提供恶意密钥，这是不可区分的。

最终的日志条目格式为：vrf-r255(电子邮件) || SHA-256(公钥)。设计透明日志条目是部署透明日志最重要的部分：它需要包含足够的信息让监控者隔离所有相关条目，但又不能包含过多信息以致构成隐私或污染威胁。

非等价性与见证网络

要获得所需的延迟集体验证，所有客户端和监控者必须看到同一日志的一致视图，其中日志保持其追加属性。这称为非等价性或分裂视图保护。换句话说，如何阻止日志操作者向客户端显示日志 A 的包含证明，而向监控者显示不同的日志 B？

在一般情况下，单独实现这一点是困难的。透明日志生态系统引入了见证共同签名者的概念：第三方运营的服务共同签名检查点，以证明该检查点与见证者观察到的该日志的所有其他检查点一致。客户端检查这些见证共同签名，以获得保证：除非足够多的见证者与日志串通，否则它们不会被呈现日志的分裂视图。

这些见证者运营效率极高：日志在请求共同签名时提供 O (log N) 的一致性证明，见证者只需要存储 O (1) 观察到的最近检查点。所有潜在的密集验证都推迟并委托给监控者，监控者可以确信拥有与所有客户端相同的视图，这要归功于见证共同签名。

这种效率使得作为公共福利基础设施免费运营见证者成为可能。见证网络收集公共见证者，并维护见证者自动配置的透明日志开放列表。

在工程实现中，Tessera 直接支持这些策略。当创建新的检查点时，它会并行联系所有见证者，并在满足策略时返回检查点。配置是简单的，增加的延迟最小（小于一秒）。策略是基于 Sigsum 策略的 DAG，可以变得复杂以满足最严格的正常运行时间要求。

实施参数与监控要点

透明日志配置参数

1. 检查点间隔：对于低流量但交互式的服务器，禁用批处理以消除第一个请求的集成延迟。保持 1 秒的检查点间隔，以免过于频繁地访问见证者；只有在两个请求快速连续到达时才会观察到这一点。

2. 检查点重新发布间隔：如果没有新条目，每天只发布一次检查点，使见证者的平均 QPS 较低。

3. 批次大小：设置为 1 以最小化延迟，tessera.DefaultBatchMaxAge作为最大批次年龄。

4. 策略配置：使用阈值策略，例如需要 3 个见证者中的 2 个共同签名，其中每个操作者可以使用 N 个见证者实例中的任何 1 个来执行。

监控实现要点

1. 服务器端：公开 Tessera POSIX 日志目录，通过 HTTP 提供/tlog/端点。

2. 客户端监控：添加-all标志到 CLI，读取日志中所有匹配的条目。监控需要下载整个日志，这是当前透明日志系统的一个扩展性限制。

3. 监控 API：提供/api/monitor端点，返回电子邮件地址的 VRF 证明和历史密钥列表。

4. 条目验证：监控时匹配哈希与服务器通过监控 API 提供的原始公钥列表。

当前限制与未来方向

当前透明日志系统仍有两个限制：

1. 监控效率：监控者需要下载整个日志。对于小型密钥服务器甚至 Go 校验和数据库来说可能没问题，但对于证书透明 / Merkle 树证书生态系统来说是一个扩展性问题。

2. 条目新鲜度：包含证明只保证公钥在日志中，不保证它是该电子邮件地址的最新条目。类似地，Go 校验和数据库无法有效证明 Go 模块代理的/list响应是完整的。

正在开发中的可验证索引设计旨在通过提供可验证的索引甚至对日志条目的 map-reduce 操作来解决这些限制。预计在 2026 年底前投入生产，而上述所有功能今天已经可用。

工程实践建议

部署透明日志的步骤

1. 选择透明日志实现：推荐使用 Tessera 库，支持对象存储或 POSIX 文件系统后端。

2. 设计日志条目格式：平衡监控需求与隐私保护，使用 VRF 保护敏感标识符，使用哈希防止污染。

3. 集成见证网络：生成透明日志密钥，向见证网络提交 PR 以添加日志配置。

4. 实现监控接口：提供必要的 API 端点供客户端和第三方监控服务使用。

5. 配置客户端验证：使用 Torchwood 解析策略并验证证明，就像验证数字签名一样。

性能优化考虑

1. 延迟敏感型服务：禁用批处理，使用较小的检查点间隔。

2. 高吞吐量场景：适当增加批次大小，平衡延迟与吞吐量。

3. 见证者选择：根据地理位置和可靠性选择多样化的见证者，配置适当的阈值策略。

4. 存储优化：POSIX 后端适合中小规模，对象存储后端适合大规模部署。

安全最佳实践

1. 密钥管理：安全存储透明日志签名密钥，考虑使用硬件安全模块。

2. 监控覆盖：确保有足够的监控覆盖，考虑部署第三方监控服务。

3. 审计日志：保持透明日志操作的所有管理操作的审计跟踪。

4. 灾难恢复：定期备份透明日志状态和数据库，测试恢复流程。

总结

透明密钥服务器代表了公钥基础设施工程的重要进步。通过不到 500 行代码的增量更改，传统集中式密钥服务器可以转变为具备强可审计性、隐私保护和防篡改能力的系统。

用户体验完全不变：用户无需管理密钥，Web UI 和 CLI 的工作方式与以前完全相同。唯一的区别是 CLI 的新-all功能，允许对日志操作者可能为电子邮件地址呈现的所有公钥追究责任。

这种工程方法的核心洞察是：透明日志证明是增强型签名，策略是增强型公钥。验证是确定性的离线函数，接受策略 / 公钥和证明 / 签名，就像数字签名验证一样。这种抽象使得透明日志技术可以广泛应用于需要可审计集中服务的场景。

随着可验证索引等技术的发展，透明日志系统的能力和效率将进一步提升，为构建更安全、更可信的互联网基础设施提供坚实的技术基础。

---

资料来源：

• Building a Transparent Keyserver - Filippo Valsorda
• C2SP Specifications - Transparency Log Ecosystem Standards