好吧,假设我有一个运行有10个客户端的DHT,其中有一堆数据。
对于恶意客户端来说,运行我的程序的备用版本不是相对容易吗?它可能会对我的数据进行潜在的破坏性操作(例如替换密钥、删除密钥、更改数据、删除我的整个DHT等)
如何防止这种情况发生?
我只能想到:
-
校验和验证程序并只允许这些程序连接。但这会被黑客入侵吗?
-
使用某种密钥验证每个DHT客户端。
有人知道如何防范这种情况吗?提前谢谢。
不要试图验证运行DHT节点的软件本身,只需根据需要验证它们提供的行为和数据。
根据数据的预期用途,有几种方法可以做到这一点。在不知道你的DHT的确切用例的情况下,我只能提供一些通用指南:
- 如果你对DHT本身之外的数据有一些信任锚(例如,用户A给用户B一个包含公钥的链接),那么就使用该签名,然后将其纳入你的协议设计中,例如,从公钥中导出DHT查找密钥,用它来验证数据上的签名,使伪造变得不可能,等等。
- 在某些情况下,使用椭圆曲线密码并具有
node ID == node's pubkey
是有用的
- 在某些情况下,使用椭圆曲线密码并具有
- 使用冗余,发布到多个节点。无论如何都应该这样做,因为节点可能会脱机/无法访问
- 另一种形式的冗余:非对称API,每个发起方发布一个值,但目标节点返回存储在其上的值列表,可能包含发起节点的IP
- 减少攻击者首先破坏DHT的动机:
- 协作发布-如果网络中的多个参与者有兴趣发布相同的数据块,那么攻击者将更难与他们竞争
- 易于重新生成数据-如果有人拒绝了密钥空间的一小部分,只需重新发布数据,则发布者的任务是将数据保存在DHT中,而不是永远依赖其他节点来维护它
- 间接/数据只是一个指针-如果DHT本身不包含攻击者可能想要删除/替换的任何"有趣"数据,而只是指向实际数据的指针,并且该指针很容易被另一个指针替换,那么攻击它就不那么有用了
- 耐污染数据-20个不良条目下的1个好条目应该仍然有用)
- 保持低复杂性-跨越多个DHT节点的脆弱数据结构/间接查找比存储在几十个节点上的单个几个字节长的字符串更容易破坏
- 提供一种稍后在更高协议级别验证数据的方法-将从DHT获得的所有信息视为暂定
- 使攻击者很难控制除DHT密钥空间的一小部分之外的任何东西
- 路由表中每个IP只有1个条目
<key,List<value>>
表中每个IP每个密钥只有一个条目- 通过从节点的外部IP派生和/或使用hashcash来限制节点ID
- 使用UDP时:写入操作需要3向握手,以避免IP欺骗
一般来说:将所有节点视为不可靠、有缺陷的节点,并将其中一些(但不是全部)视为恶意节点
信任但要核实。