3

好的，假设我有一个运行有 10 个客户端的 DHT，其中包含一堆数据。

恶意客户端运行我的程序的替代版本不是相对容易吗，这可能会对我的数据进行潜在的破坏性操作（例如替换密钥、删除密钥、更改数据、删除我的整个 DHT 等）。 ..)

我该如何防止这种情况发生？

我只能想到：

  • 校验和验证程序并只允许那些连接。但这会被黑客入侵吗？

  • 使用某种密钥验证每个 DHT 客户端。

有谁知道如何防止这种情况？提前致谢。

4

1 回答 1

5

不要尝试验证运行 DHT 节点本身的软件，只需根据需要验证它们提供的行为和数据。

有几种方法可以做到这一点，具体取决于数据的预期用途。在不知道 DHT 的确切用例的情况下，我只能提供一些一般性指导：

  • 如果您对 DHT 本身之外的数据有一些信任锚（例如，用户 A 给用户 B 一个包含公钥的链接）然后使用该签名，然后将其合并到您的协议设计中，例如从公钥派生 DHT 查找密钥，使用它可以验证数据上的签名以防止伪造等。
    • 在某些情况下，使用椭圆曲线密码学很有用，并且有node ID == node's pubkey
  • 使用冗余，发布到多个节点。无论如何，您都应该这样做，因为节点可能会脱机/无法访问
  • 另一种形式的冗余：非对称 API，其中每个发起者发布单个值，但目标节点返回已存储在其上的值列表，可能包含发起节点的 IP。
  • 首先减少攻击者破坏 DHT 的 动机：
    • 协作发布——如果网络中的多个参与者有兴趣发布相同的数据块，那么攻击者将更难与他们竞争
    • 易于重新生成数据 - 如果有人对密钥空间的一小部分进行 dDoS，只需重新发布数据，将内容保存在 DHT 中是发布者的任务，不要依赖其他节点永远维护它
    • 间接/数据只是一个指针 - 如果 DHT 本身不包含攻击者可能想要删除/替换的任何“多汁”数据，而只是指向实际数据的指针，并且该指针可以很容易地被另一个替换它攻击它变得不那么有用了
    • 抗污染数据 - 1 个好的条目低于 20 个坏条目应该仍然有用）
    • 保持低复杂度 - 跨越多个 DHT 节点/间接查找的脆弱数据结构比存储在数十个节点上的单个几个字节长的字符串更容易破坏
    • 提供一种稍后在更高协议级别验证数据的方法 - 将从 DHT 获得的所有内容视为暂定
  • 使攻击者难以控制除 DHT 密钥空间的一小部分之外的任何内容
    • 路由表中每个 IP 只有 1 个条目
    • <key,List<value>>表中每个键的每个 IP 仅 1 个条目
    • 通过从节点的外部 IP 派生和/或使用 hashcash 来限制节点 ID
    • 使用 UDP 时：写操作需要 3 次握手以避免 IP 欺骗

一般来说：将所有节点视为不可靠、有缺陷，并且其中一些（但不是全部）是恶意的。
信任但要验证。

于 2015-02-25T03:21:14.457 回答