Matrix-js-sdk密钥备份机制中的信任策略问题分析

背景介绍

在Matrix协议中，客户端密钥备份是一个重要的安全功能，它允许用户在不同设备间同步端到端加密的会话密钥。Matrix-js-sdk作为JavaScript实现，负责处理密钥备份的上传和恢复逻辑。近期发现了一个关于备份信任策略的实现问题，可能导致某些情况下密钥无法正常上传。

问题本质

当前实现中，密钥备份的信任判断存在一个逻辑缺陷。根据Matrix规范，备份信任可以通过两种方式确定：

1. 备份数据被主签名密钥(MSK)正确签名
2. 客户端拥有与备份匹配的解密凭证（通过用户输入、密钥存储或从已验证设备共享获得）

然而在matrix-js-sdk的实际代码中，只有当备份被签名时才会被视为可信，而忽略了第二种情况。这导致当用户拥有备份解密凭证但备份未被签名时，客户端会错误地拒绝上传新密钥。

技术细节分析

在rust-crypto模块的backup.ts文件中，信任判断逻辑如下：

if (!trustInfo.trusted) {
    // 拒绝上传
}

而trusted属性仅检查了签名验证结果，没有考虑解密凭证匹配的情况。正确的实现应该同时检查两个条件：

if (!trustInfo.matchesDecryptionKey && !trustInfo.trusted) {
    // 拒绝上传
}

或者在构建信任信息时就将解密凭证匹配纳入考虑：

trusted: signatureVerification.trusted() || backupMatchesSavedCredentials

影响范围

这个问题主要影响以下场景：

1. 历史备份：早期创建的备份可能未被主签名密钥签名
2. 跨客户端兼容：某些客户端可能未实现签名功能
3. 特殊配置：用户手动配置备份但未完成签名流程

在这些情况下，即使用户正确输入了恢复凭证，客户端仍会拒绝上传新密钥，导致备份功能部分失效。

解决方案建议

从安全架构角度考虑，建议采用以下改进方案：

1. 完善信任判断逻辑：按照规范实现完整的信任判断，同时考虑签名状态和解密凭证匹配情况。

2. 自动签名机制：当检测到用户拥有备份解密凭证时，自动使用主签名密钥为备份添加签名，提升安全性和一致性。

3. 状态修复工具：提供专门的修复流程，帮助用户修复未签名的历史备份，而不需要重置整个备份版本。

安全考量

虽然放宽信任策略可能带来潜在风险，但实际分析表明：

• 拥有备份解密凭证本身已构成强信任基础
• 恶意客户端可以通过多种方式破坏安全性，单纯依赖签名验证无法提供绝对保护
• 用户体验与安全性需要平衡，过于严格的策略反而可能导致用户禁用备份功能

总结

Matrix-js-sdk当前的密钥备份信任策略存在实现与规范不一致的问题。修复这一问题将提高备份功能的可靠性和兼容性，特别是在处理历史备份和跨客户端场景时。建议采用综合考虑签名状态和凭证匹配的信任策略，同时提供适当的自动修复机制，在保证安全性的同时提升用户体验。