Summary

  • 11 月 1 日的 KEYTRANS 架构第 11 版新增“客户端完整性”一节；10 月 7 日的第 10 版没有这一节。
  • 草案指出，服务运营者若向某个用户发送改动过的应用或日志配置，就能关闭证明验证与监测，或替换客户端信任的公钥。

一份公开账本可以把每笔记录写对，却管不了手机是否真的翻开它。IETF KEYTRANS 架构草案第 11 版新增的第 7.3 节，就把这道门摆在台面上。密钥透明机制检验账号与公钥的对应关系，试图让服务商暗中给不同用户看不同钥匙的动作留下痕迹。但验算证明、记住旧状态、发现分叉，都要由客户端执行。

发客户端的人是谁？草案说，通常还是服务运营者。它常同时提供应用软件和透明日志的配置，而这套机制本来就是要约束它。若它能只给某个用户换一份程序，就可以让那份程序跳过证明验证或持续监测；若它能改配置，就可以把日志或第三方的公钥换成自己掌握的钥匙。账本对其他人仍可读，受影响者的验算器却已被换掉。

10 月 7 日的第 10 版没有这一节。新版明确列出四项前提：设备安全执行代码、客户端正确实现协议、拿到真实日志配置、本地时钟准确。故障路径也不同。设备失陷可能直接泄露私钥和明文；本地状态被回滚会抹去客户端此前记住的证据；错误时钟会让过期的日志视图看起来仍能接受。

草案提出的办法各管一段。软件版本若先进入公开的追加式日志，再让客户端安装，针对个人投放的异常版本就更容易暴露。开源和可复现构建帮助外部人员检查发布的版本；验证启动、沙箱和硬件支持的密钥存储保护设备；独立来源的认证时间约束旧视图。草案并没有报告某家服务已经这样做，也没有报告一次真实攻击。

真正要问一家通信服务的，是它能否在没有公开发布痕迹的情况下，单独替换一个人的验证程序。Datatracker 页面将文件列为已提交 IESG 的活跃工作组草案。对数树算得再漂亮，也证明不了用户手机里运行的是哪一版代码。