在具有端到端加密（E2E）的Messenger中，用户对其密钥负责。当他丢失它们时，他被迫重置他的帐户。

重置帐户很危险。您擦除了公共密钥，并且在所有对话中都变成了加密陌生人。您需要恢复自己的身份，在几乎所有情况下，这都意味着召开个人会议并与每个联系人进行“安全号码”的比较。您真正多久进行一次这样的测试，这是免受MiTM的唯一保护？

即使您认真对待安全号码，每年您在一次会议上也只会看到许多聊天伙伴，因此您陷于困境。

但这很少发生，对吧？

重置多久发生一次？答：在大多数E2E聊天应用程序中，始终存在。

在这些Messenger中，您放弃加密并开始信任服务器：（1）每次切换到新手机时；（2）每当有人切换到新电话时；（3）当重置为手机的出厂设置时；（4）任何对话者将其重置为出厂设置时；（5）每当您卸载并重新安装该应用程序时，或（6）当您与之交谈的任何人卸载并重新安装该应用程序时。如果您有数十个联系人，则每隔几天就会进行一次重置。

重置发生得如此频繁，以至于这些应用程序都假装这不是问题：

看来我们已经进行了安全升级！ （但不是真的）

真的是豆腐吗？

在密码术中，术语TOFU（“首次使用时的信任”）描述了两方首次讲话时的机会游戏。调解员不是亲自开会，而是对每一方负责……然后，当事方陈述自己的立场后，每一方都仔细监控密钥以确保没有任何变化。如果键已更改，则每侧都会发出警报。

如果在这种情况下远程主机的密钥在SSH中发生更改，它将不会“正常工作”，但将变得完全好战：

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the RSA key sent by the remote host is 00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff Please contact your system administrator. Add correct host key in /Users/rmueller/.ssh/known_hosts to get rid of this message. Offending RSA key in /Users/rmueller/.ssh/known_hosts:12 RSA host key for 8.8.8.8 has changed and you have requested strict checking. Host key verification failed.

这是正确的行为。请记住： 这不是TOFU，如果允许您稍加警告便可以继续工作。 您应该看到一个带有骷髅的巨大头骨 。

当然，这些即时通讯程序会声称一切都很好，因为会警告用户。如果需要，他可以检查安全号码。这就是为什么我们不同意的原因：

未执行验证，因为它经常发生。
检查糟透了。
甚至对关心安全的朋友进行的粗略调查也表明，没有人担心此测试。
因此，它一次又一次地信任服务器并信任SMS。
最后，这些应用程序不应以这种方式工作。特别是在更换设备时。典型的正常情况可以顺利安全地处理，情况越少越糟。稍后，显示Keybase解决方案。

别叫豆腐了

这是非常有效的攻击。假设夏娃想闯入爱丽丝和鲍勃的现有对话并站在他们之间。爱丽丝（Alice）和鲍勃（Bob）通过TOFU已有很长时间了，一直保持着联系。

夏娃只是让爱丽丝认为鲍勃买了一部新手机：

鲍勃（夏娃）：嘿，嘿！

爱丽丝：哟，鲍勃！您似乎有新的安全号码。

鲍勃（夏娃）：是的，我买了一部很好的手机iPhone XS，对此非常满意。让我们在RWC 2020上交换安全号码。嘿，您有当前的卡罗琳地址吗？我在旧金山时想给她一个惊喜。

爱丽丝：我无法比拟，Android 4生活！是的，舒适街555号。

因此，大多数加密的Messenger都不太可能获得TOFU认证。这更像是TADA-添加设备后的信任。这是一个实际的问题，而不是虚构的问题，因为它为存在的对话中的恶意实施创造了机会。在真正的豆腐中，当有人对您的对话感兴趣时，他们将无法渗透。使用TADA，这是可能的。

在群聊中，情况甚至更糟。聊天中的人越多，重新安装帐户的频率就越高。根据我们的估计，在只有20人的公司中，这种情况大约每两周发生一次。公司中的每个人都必须与这个人见面。就个人而言。否则，整个聊天过程将被一名mole鼠或黑客破坏。

解决方案

有没有一个好的解决方案，并不意味着信任私钥服务器？我们认为有：真正支持多种设备。这意味着您将管理代表您的身份的设备链。当您收到新设备（电话，笔记本电脑，台式计算机，iPad等）时，它将生成自己的密钥对，并且先前的设备会对其进行签名。如果丢失了设备，请从其余设备之一“删除”它。从技术上讲，这种删除是一种重新调用，在这种情况下，还会自动发生某种类型的密钥反转。

结果， 当对话者或同事收到新设备时 ， 您无需信任服务器或亲自见面 。同样，删除服务器时，如果不是最后一个，则无需信任服务器或亲自见面。您唯一需要看到警告的时间是某人真正失去对所有设置的访问权限。在这种情况下，您将看到一个严重的警告，因为它应该：

特别丑陋

如此一来重置和重新安装更少的帐户。从历史上看，在Keybase上，设备附加组件和评论的总数是帐户释放次数的十倍 （您无需一言为定，它可以在我们的Merkle树中公开获得）。与其他Messenger不同，当您与最近重新安装了钥匙的人交谈时，我们会显示出真正可怕的警告。

设备管理是一项复杂的工程操作，我们已经对其进行了多次完善。现有设备对新设备的公钥进行签名，并为新设备的公钥加密所有重要的秘密数据。由于我们正在谈论用户的关注范围，因此应该迅速（在一秒钟之内）执行此操作。结果，Keybase使用了密钥层次结构，因此当从旧设备传输32字节的秘密数据时，新设备可以看到所有长期存在的加密数据（有关更多详细信息，请参见下面的FAQ）。这似乎有点令人惊讶，但这恰恰是密码学的重点 。它不能解决您的秘密管理问题；它只会使系统更具可伸缩性。

安全的全貌

现在，我们可以为Keybase应用程序制定四个基本的安全属性：

持久的密钥永远不会离开创建密钥的设备
全面的多设备支持，最大限度地减少了帐户丢失
密钥撤销不能被恶意延迟或回滚
使用临时时间消息直接保密

前两个似乎可以理解。在预期设备召回并认为正常的设计中，三分之一变得很重要。系统必须进行检查，以确保恶意服务器无法延迟设备审查，这是我们之前撰写的。

有关第四个安全功能的更多信息，请参见我们的临时消息文章。

许多新的加密技术，是否都正确实施？

Keybase以前从未实现过基本的安全功能，甚至从未在科学文章中对其进行过描述。我们必须自己发明一些密码协议。幸运的是，在任何情况下都有大量现成的，标准化的和广泛使用的密码算法。我们所有的客户代码都是开放的。从理论上讲，任何人都可以发现设计或实现错误。但是我们想证明其内部结构，并聘请了最好的安全审计公司进行全面分析。

今天，我们介绍了NCC集团的报告，并对结果感到非常鼓舞。 Keybase在审核上花费了超过100,000美元，NCC Group聘请了高级安全和加密专家。他们在我们的实施过程中发现了两个重要的错误，我们迅速修复了它们。仅当我们的服务器行为不当时，这些错误才会出现。我们可以保证他们不会那样做，但是您没有理由相信我们。 就是这样！

我们相信NCC团队表现出色。尊重他们花费的时间来充分了解我们的架构和实施。他们发现微妙的错误引起了我们开发人员的注意，尽管我们最近反复观察了这部分代码库。我们建议您在此处查看报告，或转到我们的常见问题解答。

常见问题

您怎么敢攻击XYZ产品？

我们已经从文章中删除了对特定产品的引用。

还有什么

我们很高兴Keybase不需要电话号码，并且可以通过加密方式验证Twitter，HackerNews，Reddit和Github标识符（如果您认识任何人）。

并且……很快……将有对Mastodon的支持。

电话重定向攻击呢？

许多应用程序容易受到重定向攻击。夏娃走进购物中心的售货亭，说服移动运营商鲍勃将鲍勃的电话号码转发到她的设备。或者她通过电话说服代表。现在，Eve可以在Messenger服务器上进行身份验证，声称她是Bob。结果看起来像我们的Alice，Bob和Eve的示例更高，但是Eve不需要渗透任何服务器。某些应用程序提供“注册阻止”功能来防御这种攻击，但默认情况下它们很烦人。

听说Keybase向服务器发送了一些私钥？

在早期（2014年和2015年初），Keybase用作PGP Web应用程序，用户可以选择该功能以将自己的私密PGP密钥存储在我们的服务器上，并使用密码加密（Keybase不知道）。

2015年9月，我们推出了新的Keybase模型。 PGP密钥在Keybase聊天或文件系统中从未使用过（也从未使用过）。

旧聊天如何立即出现在新手机上？

在其他一些应用程序中，新设备看不到旧消息，因为通过服务器同步旧消息与直接保密相反。 Keybase应用程序允许您将某些消息（或整个对话）指定为“临时”。它们会在一定时间后销毁并进行两次加密：一次使用寿命长的聊天加密密钥，另一次使用频繁更改的临时密钥。因此，临时消息提供了直接的保密性，并且无法在电话之间同步。

非临时消息会一直保留，直到用户显式删除它们并将E2E与新的Slack样式的设备同步（仅使用加密）！因此，当您将某人添加到团队中或为自己添加新设备时，消息将被阻止。

下一节将详细介绍同步。

告诉我们有关PUK的信息！

两年前，我们引入了用户密钥（PUK）。 PUK的公共部分在用户的公共签名链中进行广告宣传。机密部分是针对每个设备的公钥加密的。当爱丽丝准备新设备时，她的旧设备知道她的PUK密钥的秘密部分和新设备的公钥。它为新设备的公钥加密PUK的秘密部分，然后新设备通过服务器下载此密文。新设备解密PUK，可以立即访问所有长期存在的聊天消息。

每当Alice召回设备时，都会更改其PUK，以便除最近召回的设备外，所有其他设备均会收到新的PUK。

此同步方案与早期的Keybase PGP系统根本不同。在这里，所有涉及的密钥都具有32个字节的真实熵；在服务器被黑客入侵的情况下，它们不会用蛮力破解。的确，如果Curve25519或Go中的PRNG损坏，那么一切都会破裂。但是PUK同步并没有做出任何其他重要的密码假设。

大群聊天呢？

tL；博士组具有自己的经过审核的签名链，用于更改角色，添加和删除成员。

安全研究人员写了关于群聊中幻影用户攻击的文章。如果用户的客户端无法通过密码验证组成员身份，则恶意服务器可以将间谍软件和恶意软件嵌入组聊天中。 Keybase具有非常可靠的系统，具有特殊功能的groups形式，我们将在以后讨论。

你能谈谈NCC-KB2018-001吗？

我们认为此错误是NCC审核中最重要的发现。 Keybase积极使用不可变的数据结构来防止仅附加的服务器造成歧义。如果发生错误，诚实的服务器可能会开始逃避：“我早先告诉过您A，但是发生错误，我的意思是B”。但是我们的客户有一个共同的政策，即不允许服务器如此灵活：他们有硬编码的异常，以防发生错误。

最近，我们还推出了Sigchain V2 ：该系统解决了我们在第一个版本中无法正确预测的可伸缩性问题。现在，客户端使用从服务器提取的加密数据更加经济，从签名链尾部仅接收一个签名，而不是每个中间链接的签名。因此，客户失去了寻找特定签名哈希值的循环机会，但是我们之前使用这些哈希值来搜索此硬编码异常列表中的错误链链接。我们正在为发布Sigchain V2做准备，而忽略了隐藏在几层抽象之下的细节，因此系统仅信任服务器响应中的字段。

一旦NCC发现此错误，修复程序就非常简单：使用链链接哈希而不是链链接签名哈希来查找硬编码的异常。客户总是可以直接计算这些哈希值。

我们也可以将此错误归因于同时支持Sigchain V1和Sigchain V2所需的额外复杂性。现代客户端编写Sigchain V2链接，但是所有客户端必须在无限时间内支持旧版v1链接。回想一下，客户使用每个设备的私钥对链接进行签名。我们无法协调所有客户在合理的时间内覆盖历史数据的过程，因为这些客户可能只是离线。

你能谈谈NCC-KB2018-004吗？

就像在001中一样（请参见上文），我们同时为过时的解决方案和优化提供了一定的支持，这使我们失望，随着我们获得了更多使用该系统的经验，这似乎很重要。

在Sigchain V2中，我们减小了链的大小（以字节为单位），以减少搜索用户所需的带宽。这种节省在手机上尤其重要。因此，我们使用MessagePack而不是JSON对链链接进行编码，这可以节省很多钱。反过来，客户在这些链上签名并验证签名。 NCC的研究人员发现了棘手的方法来同时创建看起来像JSON和MessagePack的“签名”，从而导致冲突。当我们将JSON解析器从标准Go解析器切换到更高效的解析器时，我们在优化过程中不由自主地引入了这种歧义。这个快速解析器在查找实际的JSON之前悄悄地跳过了一大堆垃圾，其中包括此多语言攻击功能。该错误通过附加的输入验证得以解决。

在Sigchain V2中，我们还接受了Adam Langley的建议，即签名者在其软件包之前应加上上下文行前缀和字节\0签名，以使验证者不会因签名者的意图而感到困惑。在此上下文前缀概念的验证方面，存在可能导致其他多语言攻击的错误。我们很快用白名单修复了该缺陷。

修复这两个错误之后，服务器将拒绝多语言攻击的恶意负载，因此只有在受到感染的服务器的帮助下，才可能利用这些漏洞。

文档在哪里？

https://keybase.io/docs

在接下来的几个月中，我们将投入更多时间来处理文档。

您可以通过NCC进一步了解此声明：“但是，攻击者可以通过截断链中的后续链接来拒绝更新sigchain或将用户的sigchain还原到以前的状态”

Keybase广泛使用了不可变的仅追加公共数据结构，该结构强制服务器基础结构捕获用户标识符的一种真实表示。我们可以保证设备的撤回和组成员的删除，使受感染的服务器无法回滚。如果服务器决定显示不一致的视图，则此偏差将成为不可变公共记录的一部分。攻击发生后，Keybase客户或第三方审核员可以随时检测到不匹配情况。考虑到移动电话和计算能力有限的客户的实际限制，我们认为这些保证远远超过了竞争产品的保证，并且几乎是最优的。

简而言之，Keybase无法发明别人的签名。像任何服务器一样，它可以保存数据。但是我们的透明Merkle树旨在将它们存储在很短的时间内，并且始终可以被发现。

Keybase如何处理帐户重置？

当Keybase用户实际上丢失了所有设备（而不是添加新设备或丢失了一些设备）时，他们需要重置。重置帐户后，该用户基本上是新用户，但他具有相同的用户名。他无法签署“重置指令”，因为他丢失了所有钥匙。因此，Keybase服务器将不可擦除的语句提交给Merkle树，这意味着重置。客户强迫不可能回滚这些说明。在以后的文章中，将详细描述特定的机制。

该用户将必须使用新密钥重新添加身份验证（Twitter，Github等）。

服务器可以简单地交换某人的Merkle树叶来通告一组完全不同的密钥吗？

NCC的作者正在考虑一台敌对的Keybase服务器，该服务器完全交换Merkle树叶，用全新的伪造密钥集替换Bob的真实密钥集。攻击服务器有两个选择。首先，他可以通过将Bob放在另一个分支中，而将他想愚弄的另一个放在另一个分支中，来分支世界状态。其次，他可以通过发布带有正确Bob键集的Merkle树版本和带有伪集的其他版本来“作弊”。定期与Bob交互的用户将发现此攻击，因为他们将验证先前下载的Bob历史记录的版本是从服务器下载的新版本的有效前缀。扫描所有Keybase更新的第三方验证器也将注意到此攻击。如果您编写我们喜欢的第三方Keybase验证器，我们将提供可观的奖励。请参阅Keybase上的max。否则，我们希望尽快计划创建自主验证器。

您能相信我读到的内容吗？

阅读还是向下滚动？

键库和真正的豆腐