确保所有人的沟通！

介绍

在此博客中，我们展示了我们如何使用信号使者服务器以促进网络中节点之间的Internet上的安全通信。我们利用此基础架构运行安全的多方计算（MPC），专门运行阈值BLS签名协议。我们的开源库（用Rust编写）将现有的尚未记录的信号服务器API置换，可用于构建具有烘焙安全性和隐私属性的应用程序。

在此博客中，我们描述了我们所经过的道路，直到融合到我们认为是正确的解决方案并提供有关代码的技术细节。

疼痛

要了解我们如何决心最终建立信号，我们首先需要了解疼痛。

在为现实世界构建阈值加密系统方面，几乎没有什么明显的挑战。在这项工作中，我们专注于其中一个，即“安全渠道”：

几乎所有MPC协议都有一个共同的起点。他们在通信的一轮通信中运行，其中基本要求是针对每个两方之间的同行2对等（P2P）安全通道。最重要的是，我们可以构建简单的广播频道或发送直接消息。

什么是安全频道？

通道是发件人（爱丽丝）和接收器（BOB）之间的链接。发件人必须拥有接收器已知的唯一身份，反之亦然。这可以使用公共密钥基础架构（PKI）来实现，以便使用其公共密钥确定每个节点，并由高级权威证明。首次使用信任（豆腐）然后验证和信任网络是PKI的两个分散替代品。

安全通道提供安全消息传输；也就是说，链接中的所有通信都必须进行加密和认证。在安全的频道中，我们可以保证频道（EVE）的中间人无法学习通过该频道的信息（也许是一些元数据（例如消息长度）除外）或干预通信而没有注意到。

为了完整性，我们提到Diffie Hellman密钥交换协议：一种简单的加密协议，用作安全渠道中的主构建块。它允许发件人和接收者就联合秘密达成共识。

尽管从概念上讲简单，但实施安全渠道的实践被证明是高度不平凡的（例如，请参见TLS 1.3RFC）和容易出错。

当今的安全频道主要用例用于通过Internet进行客户服务器通信。此设置可以自然地依靠证书机构（CA）作为插件PKI。在多方/P2P设置中使用安全频道并不那么普遍，尚不清楚该设置如何与现有PKI一起使用。

最后，我们注意到可以添加某些安全属性以安全频道；例如，“远期保密”属性确保受损的发送者/接收器不会在频道中揭示过去的消息。令人惊讶的是，可以添加大量的安全属性，每种组合通常会导致键交换协议有所不同。

在哪里可以找到安全的频道？

我们最初的想法遵循了我们在MPC文献中观察到的范式：安全频道仅存在：一旦拥有MPC协议，我们就可以将其插入最方便的信任模式（即PKI），运行一些关键协议协议协议并开始加密发送。，经过身份验证（转发安全等）MPC消息。

可悲的是，这并不像我们想象的那样简单。让我们以具体的例子。Scale-Mamba是通用MPC框架。这是他们处理安全渠道的方式（来源）：

分析上述我们观察到的：

• Scale-mamba使用OpenSSL实现TLS，安全渠道最受欢迎的协议套件之一
• Scale-Mamba必须建立自己的证书授权（CA）：这是MPC当事方应信任的另一方。目前尚不清楚谁扮演这个聚会以及我们应该如何将这一新信任假设吸收到MPC协议中
• 最后，作为输出，每个MPC参与者将持有其他方的证书/公共钥匙列表。目前尚不清楚如何使用证书实际发送私人消息。或者，如果丢失了私钥或某些证书，会发生什么

作为免责声明，我们注意到Scale-Mamba是一个研究系统。

TLS实际上是一个不错的选择。它是浏览器，通用服务器和网络中应用程序中的首选协议。这是高度支持的：每个人都理解的一种语言。如我们所见，它仍然无法解决我们的问题，用户可以弄清楚如何设置PKI并留下一系列开放的问题，例如谁扮演CA的角色以及如何维护安全频道

在两个方安全计算的唯一情况下，可以使用一个不错的黑客攻击：一方可以播放Web服务器，而另一方可以使用客户端。这是在Internet上广泛使用的安全服务器客户通信的经典设置，它使基于TLS插入安全频道变得容易。不幸的是，这并不能很好地扩展到多方情况。

第二次尝试 - 噪声框架

TLS并不是镇上唯一的安全渠道协议套件。噪声协议框架是另一个这样的，可以实现真正的P2P端到端（E2E）加密。该框架是灵活的，并允许实施者在一组握手模式之间进行选择，所有这些模式都基于Diffie Hellman密钥交换，并且每个手子都可以使用特定的安全属性组合（例如，向前保密）。噪声用于某些流行应用，提供E2E加密，例如闪电网络，和线卫。这是向前迈出的一步，因为噪声似乎非常适合P2P协议。但是，当尝试使用该框架时，我们忍不住觉得MPC协议的安全频道部分从“应该存在”到需要：单独研究，找到适当的模式并与低点一起工作的主要开销级别库以实现模式。此外，一些问题仍然没有解决：首发的信任模型问题：（就PKI而言）谁是这里的“证书授权”？但是 - 如何选择正确的噪音模式？如果我选择错误的人会怎样？如果我的安全频道实施是错误的 - 它将如何影响MPC？

最后 - 使用信号

安全渠道应对用户和开发人员无缝。实际上，他们应该只是存在。

在安全渠道的景观中，独有信号规范是在中间使用转发服务器。这个想法是让服务器在同行之间路由消息。这有几个好处。其中之一与MPC相关的是将P2P频道折叠到连接到服务器的每个方向的单个通道。不利的一面是，由不参加MPC的政党运行的服务器可以DOS协议。

这种设计选择是我们以前的MPC协议构建通信层的迭代中遵循的选择：

• 多方ECDSA是阈值ECDSA实现，我们将单个HTTP服务器用作继电器
• 多方面是我们使用TCP级中介器的阈值BLS实现
• 白城市我们的努力是通过正式将单个调解人扩展到运行BFT-SMR的一组节点来消除DOS向量的努力，仅通过广播消息进行通信

使用服务器，Signal提供了一种方法，可以在同行之间构建虚拟安全通道，以保留隐私，服务器仅观察元数据。信号使用普通电话号码作为用户的唯一标识符。当电话号码进入服务器上的元数据时，这在某种程度上是隐私的，但其他情况下为我们需要的分散信任模型提供了一个显着的基础：用户将在首次使用信号时生成其Love Live公共密钥，并将注册它将服务器与电话号码一起作为她的唯一身份（在Signal Messenger中，信任模型为豆腐然后验证）。

这信号规格跨四个不同的部分：

1. 数字签名（命名为Xeddsa），主要用于关键协议中，以验证发件人身份
2. 键交换（或密钥协议）协议名为X3DH。此差异Hellman密钥交换为用户确定安全频道的安全属性（例如向前保密）
3. 安全的消息交换协议。该算法（名为Double Ratchet）假设了一个成功的钥匙交换
4. “芝麻”：本部分讨论了服务器的拟合方式。它将上述协议适应异步环境并讨论会话管理。

这些元素的组合为我们提供了所需的安全渠道。我们现在面临的挑战是如何在我们自己的应用程序中使用它们，或者除了发出信号之外的任何其他应用程序。我们接下来要提出的项目就是这样做的：允许任何应用程序设置信号服务器并通过它运行该应用程序，从而立即为应用程序提供E2E加密，经过身份验证（以及更多）安全频道。

还有一件事：如果运行自己的信号服务器不是一个选项，我们在演示中显示如何使用现有的Signal Messenger应用程序服务器。我们的希望是，在我们的图书馆建立的应用程序开发人员将运行并维护自己的信号服务器，甚至将为需要进行隐私测试和运行应用程序的其他开发人员免费提供它们。

无论如何，滥用信号Messenger服务器运行您的应用程序。我们使用它的代码仅用于演示目的。我们完全支持信号基础及其原因。这是向信号捐款的方法：https://signal.org/donate/

信号服务器代码为开源并且有非正式的说明有关部署它（例如这里，，，，这里）。

我们的实施

我们实施了图书馆这允许使用信号在节点之间建立安全的通道。还有一个演示显示如何使用库运行阈值BLSKeygen＆签名。

演示视频：https://www.youtube.com/watch?v=g15vgg4cmau

现在，我们仔细研究了演示的各个步骤，以解释技术细节！

与信号帐户链接

要通过信号进行通信，我们将需要一个信号帐户。在库中，我们仅提供与现有帐户链接的能力。创建新帐户是通过下载信号使者完成的。

链接过程与链接桌面信号应用程序相同：我们提示QR码并要求使用电话扫描。无需登录或密码。

注意：运行自托管信号服务器时，我们需要构建一个移动应用程序，可以使用非官方说明（例如这里）。

与台式机信号一样，QR码包含从服务器获得的短暂公钥和唯一标识符。移动应用不对称地使用QR码中包含的公共密钥对其信号键（身份，配置文件私钥等）进行加密，并使用QR码中包含的唯一标识符通过信号转发服务器将其发送到新设备。

使用相同的唯一标识符，新设备接收加密的键，并使用其短暂的私钥对其进行解密。现在，新设备配备了打开安全频道所需的所有秘密数据。新设备需要在服务器上注册为新设备，生成PRE键（签名的PRE键 +束式的一次性预键），并也注册它们（即，拨打更多API调用）。之后，我们获得了一个功能齐全的设备，可以发送和接收消息！

一些值得一提的笔记：

1. 我们的代码实现从头开始链接的设备：从技术上讲，我们实现了信号的子协议并逆转了设计消息加密算法。
2. 如果使用Signal Messenger服务器，建议链接到不用于消息传递的专用帐户。否则，您的其他设备（最多可以链接5）将接收MPC消息（如下所述，它们将被忽略，但仍将忽略）。
3. 我们的客户在文件系统上留下一个包含敏感信息（例如私钥和设备凭据）的文件。该文件应保持安全 - 任何访问此文件的人都可以轻率地攻击通道。

消息传递

在我们真正开始消息传递之前，各方必须交换他们的公共身份。在演示中，这是通过发送带外的地址列表来完成的。

一旦我们获得了链接的设备，发送和接收消息就很简单。要接收消息，我们建立了使用已熟悉的安全websocke连接（从链接部件）Websocket-Resource设计。发送消息是对信号API的简单放置请求。

发送和接收遵循芝麻算法，主要在锈蚀箱中实施libsignal-protocol，我们只需要将API调用放在适当的位置即可。

除了芝麻算法外，我们已经迈出了一步。芝麻暗示，发送给收件人的任何直接消息都应发送到其每个设备，服务器执行此规则。这对我们来说是不可取的：我们希望仅通过MPC设备收到MPC消息。我们使用黑客攻击，因此MPC设备接收其MPC消息，而其他设备会收到不当格式的消息，这些消息将被丢弃。

与常规信号客户端相比，另一个差异：我们将每个传出的消息预先介绍一个特殊标签，允许我们确定它是否是MPC消息，因此我们可以在解密前避免处理无关紧要的消息。如果我们将MPC设备与个人信号帐户链接在一起，则可能会出现无关的消息：手机收到的任何直接消息也将由MPC设备收到（但已删除）。

结束思想

该项目旨在制定需要安全渠道但无法负担整个基础设施的开销的实用应用。

多年来，通过领导消息传递应用程序实施了信号协议。到目前为止，可以肯定地假设该协议是合理的和战斗测试的。

运行信号协议为一些很酷的功能打开了大门，该功能旨在专门与Signal Messenger配合使用。一个这样的例子是多播信号私人组系统。我们希望我们的代码能够使这些功能可用于其他用例，并且迫不及待地想看到人们会提出的应用程序。

致谢

我们要感谢大卫·黄，，，，克劳迪奥·奥兰迪（Claudio Orlandi）和Ittay Eyal用于审查和评论此博客。我们感谢Ittay Eyal为了他的指导。