[开源] 审计日志说自己没被改过——这算不算自证清白？

本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：

- 我的帖子已经打上 开源推广 标签： 是

- 我的开源项目完整开源，无未开源部分： 是

- 我的开源项目已链接认可 LINUX DO 社区： 是

- 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是

- 以上选择我承诺是永久有效的，接受社区和佬友监督： 是

以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出

在全都是ai项目的开源社区中，我做了一个这样的开源软件。 我不擅长写推广贴，但是有推广之心，大家也可以把这个看成技术分享。

老板问：

昨晚谁改了生产权限？

运维查了一遍：

审计日志里没有这条操作。

老板又问：

审计日志存在哪？

我们数据库里。

谁能改？

还是我们。

这就有点尴尬了。

审计日志如果是内部审计肯定没问题，但真出了事故，仅仅拿出一张自己保管的日志表，很难说服另一方：

- 你怎么证明这条记录不是后来补的？

- 又怎么证明原来的记录没有被删掉或换掉？

- 掌握日志的人，能不能同时改日志？

TrustDB 是我对这个问题的一次尝试。

它做的是把已经产生的关键审计记录，变成一条可以独立验证的证据链。

项目地址：GitHub - ryan-wong-coder/trustdb: 高可信的存证系统 · GitHub

官网：https://www.trustdb.ryan-wong.cn/

一个数据有没有变动，不能只告诉第三方一句"请相信我们"

一条比较完整的审计记录，通常会写明：

- 谁执行了操作

- 操作了什么对象

- 执行了什么动作

- 操作前后的状态摘要

- 请求编号或任务编号

- 记录产生时间

- 业务附加信息

这些内容可以来自业务系统、网关、发布平台或独立审计代理。

TrustDB 首先计算记录正文的 SHA-256，再把内容摘要、长度、客户端身份、密钥编号、事件类型、时间、随机数和元数据组成一份客户端声明。

接下来由审计记录的产生方签名。```
input =
"trustdb.client-claim.v1"
|| 0x00
|| canonical_cbor(claim)

signature = Ed25519.Sign(client_private_key, input)
```这里使用确定性 CBOR，而不是随手生成的 JSON。

因为数字签名面对的是字节，不是"看起来差不多的意思"。JSON 字段顺序、空格和数字写法不同，都会产生不同字节。确定性 CBOR 把编码固定下来，让签名方和验证方得到完全相同的输入。

解码时还会拒绝重复字段、未知字段、CBOR tag、不定长编码、NaN、无穷大和尾随数据。

做这么多主要是怕把两个解析器把同一段数据理解成不同意思。

为什么签名前要写一串固定文字

TrustDB 的客户端声明、服务端回执和全局日志树头，都使用 Ed25519 签名，但它们不能共用同一种签名语义。

所以每类数据都有自己的签名域：

- trustdb.client-claim.v1

- trustdb.accepted-receipt.v1

- trustdb.committed-receipt.v1

- trustdb.signed-tree-head.v1

客户端声明只能当客户端声明验证，接受回执只能当接受回执验证。

不能拿着一份合法的客户端签名，换个外壳说它是服务端回执；也不能把旧格式里的签名塞进新格式继续使用。

记录编号同样绑定了声明和客户端签名：```
record_id =
SHA-256(
"trustdb.record-id.v1"
|| 0x00
|| claim_cbor
|| client_signature
)
```因此，两条正文相同的审计记录，只要产生方、时间、随机数或签名不同，就会得到不同编号。

内容相同，不代表是同一次操作。

客户端签名，只能证明"记录是谁生成的"

客户端签名能够证明：

持有对应私钥的一方，签过这条审计声明。

但它不能证明 TrustDB 服务端确实收到。

所以服务端还会签发两种回执。

接受回执表示：

我验证了客户端签名，并且接受了这条记录。

提交回执表示：

这条记录已经进入某个 Merkle 批次，位置和批次根如下。

"收到"和"已经进入可验证批次"被明确分开。

如果客户端声称提交过，服务端却说没收到，可以检查接受回执；如果服务端声称记录已经入账，可以继续检查提交回执和 Merkle 证明。

这比查一列 status=success 麻烦，但数据库里的状态可以被管理员直接修改，签名回执却不能在没有私钥的情况下重新生成。

Merkle 树让一条记录牵动整批记录

每条服务端记录先计算叶子哈希：```
leaf = SHA-256(0x00 || canonical_cbor(server_record))
``两个节点合并时：``
node = SHA-256(0x01 || left || right)
```0x00 和 0x01 用来区分叶子与内部节点，避免两种对象互相冒充。

一条记录进入批次后，会得到一条通往批次根的证明路径。

验证器重新计算这条路径，就能检查：

这条审计记录是否真的属于这个批次根。

有人修改记录正文，内容哈希会变；客户端声明和记录编号随之变化；Merkle 叶子、路径和批次根也会跟着变化。

想只改一条审计记录，却保持原来的批次根不变，需要找到 SHA-256 碰撞。

这已经不是改一行数据库的问题了。

如果管理员把整批记录一起重做呢

只做一层 Merkle 树还不够。

服务器管理员可以丢掉旧批次，重新生成一批记录，再拿出一个新的批次根。

因此 TrustDB 会把每个批次根继续写入全局透明日志。

全局日志本身也是一棵持续增长的 Merkle 树。每次追加后，服务端都会生成带签名的树头 STH，里面有：

- 当前树的大小；

- 当前根哈希；

- 日志编号；

- 节点编号；

- 生成时间；

- 服务端签名。

这里有两种证明。

包含证明回答：

这批审计记录是否真的进入了全局日志？

一致性证明回答：

今天的全局日志，是否由昨天的日志继续追加得到？

假设昨天有一万个批次，今天有一万零三个。一致性证明检查的不是"今天这棵树能不能算通"，而是昨天那一万个批次有没有被原样保留下来。

这样就不能趁夜里换掉一段历史，再重新生成一棵结构正确的新树。

如果服务端给不同的人看不同历史呢

透明日志仍然可能出现分裂视图。

管理员给甲看一份 STH，给乙看另一份 STH，两边单独验证都能通过，但看到的历史不同。

所以，TrustDB 可以把 STH 的全局根继续提交给 OpenTimestamps。

提交出去的只是一个 32 字节哈希，不包含审计记录正文，也无法从中还原业务数据。

证明关系变成：```
审计记录
↓ SHA-256
客户端声明
↓ 客户端 Ed25519 签名
服务端回执
↓ 批次 Merkle 证明
批次根
↓ 全局透明日志
签名 STH
↓ OpenTimestamps
外部时间见证
```OpenTimestamps 日历服务器会先返回待确认的时间戳证明，后续还可以升级到比特币区块见证。

它能帮助证明的是：

与这条审计记录相连的全局根，最迟在某个时间以前已经存在。

它不能证明审计内容本身符合事实，也不表示审计记录正文被上传到了外部网站。

验证器不会相信证明文件自报家门

TrustDB 可以把客户端声明、服务端回执、Merkle 路径、全局日志证明、STH 和外部锚定放进一个 .sproof 文件。

文件里虽然有 proof_level，但验证器不会因为它写着 L5，就直接认定达到 L5。

验证时会重新计算：

- 审计记录正文的长度和 SHA-256；

- 客户端声明的确定性 CBOR；

- 客户端 Ed25519 签名；

- 记录编号；

- 服务端接受回执；

- 服务端提交回执；

- Merkle 叶子和批次根；

- 批次根到全局 STH 的包含证明；

- STH 的服务端签名；

- 外部锚定与 STH 根是否一致。

能算到哪一层，才算达到哪一级。

证明文件说自己是 L5，和嫌疑人说自己无罪一样，只能作为提示，不能作为结论。

它能防事后改账，不能防一开始就不记账

这是审计场景里必须说明的边界。

如果某次操作从一开始就没有进入审计采集端，TrustDB 不可能凭空知道它发生过。

如果审计客户端私钥已经被控制，攻击者也可以签署新的虚假记录。

如果业务系统把错误的操作者身份交给审计端，密码学只会忠实地保护这个错误身份。

TrustDB 主要解决的是：

一条审计记录一旦被签名、接受并进入证明链，后来还能不能悄悄修改或替换。

至于"是否每次操作都生成了审计记录"，仍要依靠独立采集、连续序号、权限隔离和业务制度。

一个防改，一个防漏，不是一回事。

最后

TrustDB 目前使用：

- SHA-256；

- Ed25519；

- Core Deterministic CBOR；

- RFC 6962 风格 Merkle 树；

- 签名树头；

- 包含证明和一致性证明；

- OpenTimestamps 外部锚定；

- 可离线验证的 .sproof v1。

代码、证明格式和测试向量全部公开。

如果佬友们做过操作审计、发布审计、权限变更审计、数据流通记录或者密码学、区块链研究，欢迎从实际情况里挑问题，提issue

注：使用大模型从邮件中复制后重新md格式，当前版本无润色内容（确信）