BIP 324 点对点加密传输协议简介

作者：BIP324 homepage

来源： https://bip324.com/

引言

BIP324 提出了一种新的比特币点对点通信协议，其特性有：伺机自动加密（opportunistic encryption）、节约少许带宽，以及可以在交换应用消息前协商更新。

完整的说明书已经形成，并可以在 这里 讨论。此处仅列出动机和设计目标。

动机

比特币是一种免许可的网络，其目标是对公开的数据达成共识。因为所有数据都在比特币点对点网络中转发，所以天生就是公开的；而现在的点对点协议缺乏密码学身份的概念，对等节点们在不加密和无身份验证的连接中交谈。不仅如此，当前的 P2P 协议（在本说明书中以 “v1” 指代）的明文特性，在应对以下几种攻击时有缺陷：

• 虽然被转发的数据自身是公开的，但相关的元数据可能会泄露隐私信息并妨害用户的隐私性。举个例子，一个窃听所有比特币点对点连接的全局被动攻击者可以轻松识别一笔交易的来源节点和发起时间。
• 因为连接没有身份验证，这样的连接可以低成本地伪造，而且被检测出来的风险也不高。举个例子，攻击者可以实时（on-the-fly）替换一个连接中的特殊字节（例如节点标签 node flag），而且不需要保存任何状态。
• 当前的协议是自我暴露的（self-revealing）。举个例子，深度包检测（deep packet inspection）可以轻易识别一个 P2P 连接，因为连接总是从固定序列的魔术字节（magic bytes）开始。检测连接的能力，产生了审查的可能性，并让上述攻击以及其它需要供给制控制网络受害者（例如针对矿工的 “日蚀攻击”）都变得更加容易。（译者注：“日蚀攻击” 指的是多个恶意节点垄断一个节点的对等连接、使其失去获得比特币网络新信息的能力。）

这个新版的 P2P 协议（v2）致力于通过可持续地提高这些攻击的成本来优化网络，主要方法是使用无身份验证的伺机加密传输。此外，对被动的窃听者来说，被传输的字节流也将是伪随机的（即，跟均匀随机的字节无法分别）。

• 加密，甚至在没有身份认证的时候、仅当两方都支持 v2 的时候，也能迫使攻击者变成主动攻击，从而阻止窃听：攻击者要么必须要么进行持续的中间人（MitM）攻击，要么让连接降级至 v1，要么启动自己的节点并让诚实节点连接到他们。一般来说，主动攻击者想要扩大规模，就要花费更多资源；不过，在手动、故意连接的情况（有别于自动的、随机的连接）下，原则上来说他们无法隐藏自己：即使只是非常基本的检查，例如节点运营者手动比较协议的版本号和会话 ID（在本提议中都有设计）都会暴露攻击者。
• 伪造，就其本身来说已经是一种主动攻击；如果攻击者还不得不为了充当中间人而维护必要的通信状态的化，攻击成本会更高。
• 伪随机的字节流排除了基于模式匹配（pattern matching）的识别技术，并让字节串的塑型（模拟互联网上的其它协议）更容易。这提高了连接审查型防火墙的成本，强迫他们要么换成完全的中间人攻击，要么换成更明显的白名单制，而不能继续使用黑名单制。

为什么加密不加入身份验证？

如上所述，无身份验证的加密已经提供了严格优于不加密的安全性。因此，所有连接都应该加密，即使并不包含身份验证。

至于身份验证本身，它的好处就不像加密那么清楚了。因为比特币的免许可特性，身份验证只能受限于特定场景（例如，连接的两个对等节点属于同一个运营者），而且某一些形式的（可能是部分匿名的）身份验证是否可取，还取决于相关对等节点的具体要求。因此，我们认为，身份验证应该单独处理（如果需要的话），而 v2 致力于为未来的协议更新 —— 包括加入可选的身份验证，见 “ 私密身份认证协议” —— 提供一个可靠的技术基础。

为什么有了伪随机的字节流，还是能被流量分析？

流量分析（traffic analysis），例如观察通信包的长度和发送时机，加上主动攻击，依然可以揭晓人们正在使用比特币 v2 点对点协议。然而，伪随机的字节流提高了持续指纹识别的成本，而且可能强迫某一些中间人攻击任何他们无法识别的协议，从而造成连带的成本。

伪随机的字节流不会自我暴露（self-identifying）。而且，它没有强烈的倾向性，因此是类似协议的一个常规选择（canonical choice）。那么，比特币的点对点流量将跟其他作出类似选择的协议 —— 例如 obfs4 以及近期提出的 cTLS 插件 —— 没有分别。而且，流量塑型和协议封装（比如，发起看起来像 HTTPS 或 SSH 的流量）可以进一步缓解流量分析和主动攻击。不过，这已经超出了本提议的范围。

为什么不使用一种安全隧道协议？

我们的目标之一是让伺机加密变得无处不在，因为它对大规模的攻击提供了最好的防护。这意味着，既要保护节点运营者指示自己的软件发起的手动的、故意的连接，也要保护比特币节点根据 goosip 所提供的 IP 地址发起的自动连接。虽然加密自身已经可以通过代理网络（或者说 VPN 网络）实现，但这些对大规模的自动连接来说是不理想的，也难以应用：

• Tor 和 I2P 这样的代理网络引入了一个专门的地址空间，独立于网络的拓扑图；因为地址的成本很低，日蚀攻击会变得更便宜。相比之下，IPV4 和 IPV6 这样的清网，获得多个模糊的网络身份（也就是众所周知的 “网络分区”）的代价并不低。因此，让一大部分节点排他性地只使用这种连接方式，是不可取的，因为它会显著降低日蚀攻击的开销。除此之外，Tor 连接伴随巨大的带宽开销和时延代价，可能并不适合全体网络用户。
• 像 WireGuard 和 OpenVPN 这样的 VPN 网络，定义了一种私人网络，需要手动的配置，因此并不是自动化连接的现实选择。

因此，为了实现我们的目标，我们需要这样一种解决方案：开销最小、无需配置就能工作、总能启用 —— 能够建立在任何网络层上，而不是变成网络层的一部分。

为什么不使用通用的传输加密协议？

虽然可以依赖现有的传输加密协议，比如 TLS 和 Noise，比特币点对点网络的特殊要求，让这些协议变成了不合适的选择。

现有的这些协议无法满足的主要要求是对加密和身份验证 的充分模块化处理。就像我们上面说的，在比特币点对点网络中，无论哪一种身份验证，是否可取都取决于相关对等节点的具体要求（因此会导致有身份和无身份两种连接的混合），因此，身份验证技术应该跟加密技术解耦。但是，对少数标准的身份验证技术（例如，电子签名和证书）的支持是现有的通用传输加密设计的核心。这种对身份验证的关注，并不能给比特币点对点网络带来清晰的好处，反而会带来大量额外的复杂性。

相反，我们的提议致力于简单的模块化设计，可以单独实现地址身份验证。我们的提议通过导出一个 “会话 ID”（加密通道的唯一标识符），提供了身份验证的基础。在加密通道建立之后，两个端点可以使用任何身份验证协议，来确认他们拥有相同的会话 ID。（这个特性有时候被称为 “通道绑定”，因为会话 ID 将加密通道绑定到身份验证协议。）因为在我们的提议中，任何身份验证都需要在加密连接建立之后才能运行，我们为这种模块化付出的代价是，可能往返次数会更高（跟其它通过 Diffie-Hellman 密钥交换执行身份验证的其它协议相比）。但是，由此产生的连接建立的时延升高，对比特币的长期连接（ 一般会持续几小时甚至几周）来说并不是一个问题。

除了这种在身份验证的处理上的根本分歧，使用 TLS 或者 Noise 在我们这个场景中还会产生别的技术问题：

• 不能提供伪随机的字节流。
• 不能提供对基于 secp256k1 曲线的椭圆曲线密码学的原生支持（而比特币就使用它们）。虽然使用 secp256k1 并不是严格必需的，但对于任何用在比特币中的新的非对称密码学来说，它都是一个显然的选择，因为这样做可以尽可能减少密码学强度假设，以及比特币软件所需的依赖。
• 不能提供字节流的可塑性。
• 都为应用层提供了基于流（stream）的接口，但比特币需要一个基于包（packet）的接口，因此需要额外的薄薄一层来执行包的序列化和解序列化。

虽然现有的协议可以通过一系列的改造来解决所有这些问题，但这样也削弱了将他们作为开箱即用的工具的好处，比如，可以复用现有的实现的安全分析。

目标

本协议希望实现下列特性：

• 防范被动攻击的机密性：可以记录一个 v2 点对点字节串（但没有时机和分段信息）的被动攻击者无法确定节点所交换的明文。
• 主动攻击的可检测性：一个会话 ID 唯一地对应到一条加密的通道，是从 Diffie-Hellman 协商中确定性地派生出来的。主动的中间人攻击将被迫冒着被检测出来的风险，因为对等节点的运营者可以手动改变会话 ID，或者使用可选的身份验证手段（未来的协议版本可能引入）。
• 伪随机的字节流：可以记录一个 v2 点对点字节串（但没有时机和分段信息）的被动攻击者无法分辨它跟均匀随机的字节流。
• 可塑型的字节流：可以改变字节流，以提升对流量分析的抗性（举个例子，为了隐藏区块传播），或者 回避审查。
• 前向保密（forward secrecy）：一个攻破了某个会话的窃听攻击者无法解密以前的会话流量，只能解密最新的少数几个包。
• 可升级：本协议使用版本号提供了升级功能，可用于在未来添加身份验证、PQC 握手升级等等功能。
• 兼容性：v2 客户端将允许是入站的 v1 连接，以尽可能降低网络分区的风险。
• 低开销：新的 P2P 传输协议的引入，不应使实现它的节点的计算开销和带宽开销显著升高（与当前的协议相比）。

加入进来

本协议的代码已接近完成，正在社区参与阶段。我们希望在以下方面得到您的帮助：

• 审核我们的 BIP
• 审核代码
• 在主网运行一个启用了 BIP324 的 v2 节点
• 在协议公告版上监督开发进度

• 本文转载自： btcstudy.org/2023/06/08/... , 如有侵权请联系管理员删除。