高级的E2EE——交叉签名（区块链密码签名）（第二篇-签名状态篇）

根据签名显示验证状态

交叉签名的一般思想

交叉签名的总体思路是，无需每个设备都必须验证其他设备，人们只需验证其他人，并且您只需验证自己的每个新会话（登录）一次。为此，每个用户都有三个密钥：主密钥、自签名密钥和用户签名密钥。主密钥将对自签名密钥和用户签名密钥进行签名。然后，自签名密钥将签署您自己的设备密钥，而用户签名密钥将签署其他人的主密钥。将其拆分为三个密钥的目的是，在自签名密钥或用户签名密钥被泄露的情况下，您可以轻松交换它们，同时仍保留主密钥。由于主密钥仅用于签署您自己的用户签名和自签名密钥，很少使用，因此获得它的攻击面很小。或者，设备密钥本身可以签署自己的主密钥。

因此，除了其他人的设备密钥，我们还需要获取他们的交叉签名密钥。然后我们可以验证他们的签名！

交叉签名密钥

除了设备密钥之外，还引入了交叉签名密钥。它们不是通过密钥 ID 来识别，而是通过它们的公钥来识别。为了防止冲突，家庭服务器必须确保没有用户拥有与交叉签名密钥的公钥相同的密钥 ID。这很方便，因为这意味着作为客户，我们不必关心那部分！

跟踪交叉签名密钥

如果您已经为设备密钥跟踪交叉签名密钥，则应该很简单。当用户被标记为过期时，您应该已经再次查询他们的密钥POST /_matrix/client/r0/keys/query 并相应地更新您的device_keys字典，就像以前一样。这个端点现在还应该返回用户的master_keys,self_signing_keys和user_signing_keys，因为他们正在使用交叉签名。只需在本地更新和存储此信息。这些格式与device_keys字典非常相似：

{"self_signing_keys": {"@bob:example.org": {"user_id": "@bob:example.org","usage": ["self_signing"],"keys": {"ed25519:base64+self+signing+public+key": "base64+self+signing+public+key"},"signatures": {"@bob:example.org": {"ed25519:base64+master+public+key": "signature+of+self+signing+key"}}}}
}

在这个例子中，我们有 Bob 的自签名密钥，它具有 Bob 的主密钥的签名。该usage 数组还指示键的用法，master即self_signing或user_signing。虽然对于交叉签名应该只有一项usage，但将来可能会添加一些其他可能具有多种用途的密钥。因此，这里使用数组来保证未来的发展。

和部分master_keys看起来user_signing_keys相同。

密钥验证的更改

现在，您需要对我们之前实现的密钥验证（特别是 SAS）进行轻微更改：在m.key.verification.mac回复中，将有一个 MAC 字典来验证某些密钥。这些不仅包含设备密钥，还包含由标识的交叉签名密钥 ed25519:base64+master+public+key等。请务必将这些交叉签名密钥也标记为已验证。

根据交叉签名状态获取验证级别

如果您想知道设备密钥是否经过验证，只需递归检查密钥的所有有效签名，直到您点击已验证的密钥！这意味着给定一个签名链如下（假设你是 Alice）：

Alice 的主密钥 --> Alice 的用户签名密钥 --> Bob 的主密钥 --> Bob 的自签名密钥 --> Bob 的平板电脑

并且您之前（通过例如表情符号验证）验证了 Alice（您自己的）主密钥，并且想知道 Bob 的平板电脑是否经过验证，您可以向后传播该链，前提是所有签名都是有效的，直到您点击验证的主密钥。

验证签名

它有一种方法可以轻松验证签名！如果您有密钥 A 并且想要验证密钥 B 添加的签名，则必须执行以下操作：

在密钥 Asignatures字典中，找到密钥 B 的条目并记下签名。
创建用于验证的字符串：获取密钥 A 的完整字典，剥离unsigned 和signature字典并将其转换为规范的 json。
用于olmutil.ed25519_verify(key_b_pub_key, canonical_json, signature);验证签名：注意如果无效会抛出错误，如果有效则不会。
就是这样，你已经验证了签名！

检查用户是否经过验证

要查看用户是否经过验证，只需检查他们的主密钥是否经过验证！您可以通过查找用户数组中master的交叉签名密钥来找到用户的主密钥。

如果用户已通过验证，但其所有设备均未通过验证，则最好显示警告。

需要注意的事项

永远不要相信无效的签名。就像根本没有签名一样对待它们。
将存在签名循环。为您的签名循环检查添加无限递归保护。
虽然签名检查似乎并不昂贵，但在程序运行时将结果缓存在内存中可能是个好主意。
如果您在同步循环中被告知他们需要更新，请务必查询用户的密钥（如果您之前正确实施了此操作，则此处没有任何更改）。
您也可以递归直到找到自己的经过验证的主密钥，而不是递归直到找到有效密钥。然而，这在实践中不允许在设备-设备验证和交叉签名验证之间轻松迁移。因此，递归直到您点击经过验证的设备是首选。