Threema多设备：体系结构概述

如今，许多聊天服务允许用户并行使用多个设备。因此，人们可能会认为这样的多设备功能必须足够容易实现。只要安全和隐私保护不是主要的优先事项，这个概念就不远了。然而，如果需要多设备协议来满足Threema标准，事情就变得复杂了。

当然，为了满足Threema的要求，多设备解决方案必须提供完全的端到端加密。这是理所当然的。但最重要的是，它还必须排除服务器更改关键材料的任何可能性，并且必须将传输的元数据数量保持在绝对最小。

尽管这些要求构成了真正的技术挑战，但我们相信已经找到了一个有能力的、优雅的解决方案，该解决方案目前正在开发中，将于2021年推出。对于技术倾向的读者，我们在下面概述我们的方法。

根据Occam‘s Raporer的说法，比起复杂的解决方案，更喜欢简单的解决方案是明智的，就安全而言，这一原则肯定是正确的。关键组件中移动的部件越少，评估系统安全时漏洞被忽视的风险就越低。

Threema的聊天服务器可能是我们基础设施中最优化的部分，它坚持“保持简单”的座右铭，除了安全方面的好处外，还有其他原因让它保持这种状态。

首先，不是每个人都会使用多个设备，就经典的单设备用例而言，没有必要更改任何内容。另一方面，聊天服务器从来没有设计成并行处理使用相同Threema ID的多个设备。

我们决定采取一条不同的路线，而不是通过扩大聊天服务器的职责范围来使我们的基础设施的一个关键部分变得复杂。

一个新的“中介服务器”将充当共享Threema ID的设备的交换中心。该中介服务器的主要任务是：

让我们逐一仔细看看这些任务。我们将从身份验证过程开始。

基于服务器的多设备功能的一个基本要求是将多个设备组合成单个实体的某种分组机制。当然，Threema ID可以作为建立这种联系的标识符。但是，中介服务器不需要知道一组设备属于哪个特定的Threema ID。

我们不使用Threema ID本身，而是从与ID关联的私钥中派生出一些加密密钥材料：

首先，我们从Threema ID的私钥导出“设备组密钥”。此设备组密钥将用于加密共享ID的设备之间交换的数据。

接下来，我们从设备组密钥派生“中介路径密钥”。中介路径密钥将用于向中介服务器进行身份验证。服务器使用该密钥的公共部分作为用户设备的标识符；因此，它被称为“设备组ID”。

设备通过基于中介路径密钥解决认证质询来向中介服务器认证其自身。每个设备都能够独立地完成密钥导出。由于中介服务器无法确定密钥来自哪个Threema ID，因此我们建立了匿名设备分组机制。而且因为所有密钥材料都派生自Threema ID的私钥，只有客户端才能访问，所以服务器不可能更改密钥材料。

身份验证过程完成后，中介服务器将当前连接到该服务器的设备之一指定为“领导者”。该设备被分配了一项重要任务：每当它接收到来自聊天服务器的消息时，它必须处理该消息并通过中介服务器将其“反映”(即转发)到其他设备。同样，任何发送消息的设备都必须将该消息反映给其他设备。反映的消息使用设备组密钥进行端到端加密。

将消息反映到组中所有其他设备的机制是多设备功能的最基本组件。虽然这听起来微不足道，但魔鬼总是在细节中。

Threema的大多数消息类型都会在收件人的设备上触发某种反应。这里有两个例子：

如果收到邮件并且启用了已读回执，则至少有一个设备必须将已读回执返回给发件人。

如果收到来自未知联系人的消息，则必须将此联系人添加到联系人列表中，并在该列表中分配姓名和其他属性。所有设备上的这些属性必须相同。

就传入消息而言，上下文始终是相关的。通常，当接收到消息时，必须在引导器设备上触发反应，而引导器以外的设备不应该对传入的消息作出反应。

根据这条经验法则，上面的第二个示例中会出现一个问题：在除引导者之外的设备上没有反应的情况下，新联系人将仅添加到引导者设备的联系人列表中，而不会添加到其他设备的联系人列表中。这就是设备同步发挥作用的地方。

如果多个设备共享一个Threema ID，则每个设备上不仅需要显示新消息，还需要在所有设备上同步联系人、群聊、通讯组列表和用户设置。因此，中介服务器还分发从未通过聊天服务器的数据。

同步随之而来的是冲突的可能性。例如，如果在两个设备上同时设置了不同的简档图片，则在最坏的情况下，两个设备都可能以由相反的设备设置的简档图片结束。为了防止出现这样的不良结果，需要一种机制来临时授予设备对中介服务器的“反射消息队列”的独占访问权限。但是，对事务机制的解释超出了本概述的范围。

Threema的聊天服务器使用TCP作为传输协议。出于技术原因，我们暂时让读者发挥想象力，中介服务器需要WebSocket支持。中介服务器将支持该协议，而不是为聊天服务器配备WebSocket协议，并且聊天服务器和多设备客户端之间的通信将通过中介服务器进行代理。

这种代理技术的一个受欢迎的副作用是聊天服务器无法将IP地址与Threema ID相关联。多亏了匿名设备分组，同样的情况也适用于中介服务器。

当然，虽然Threema将提供官方中介服务器，但如果用户愿意，也可以自行托管他们自己的中介服务器。这样，用户只会向Threema的聊天服务器泄露他们的中介服务器的IP地址，而不会泄露他们的设备的IP地址，从而再次减少了Threema端的元数据数量。

正如我们已经看到的，如果安全和隐私保护是多设备功能的主要要求，则需要克服相当多的障碍。

Threema的解决方案提供完全的端到端加密。我们协议的加密属性使得服务器不可能更改密钥材料。而且，在真正的Threema方式中，由于匿名设备分组和可自我托管的中介服务器，元数据的数量被保持在绝对最小的水平。

当然，在这个粗略的提纲中，我们还有许多其他方面没有触及。虽然我们正处于开发阶段，技术细节仍有可能更改，但基本框架已经建立。