search

ipfs / specs

Technical specifications for the IPFS protocol stack
https://specs.ipfs.tech
1.16k stars 232 forks source link

Are peerinfo objects authenticated? #73

Open wanderer opened 8 years ago

wanderer commented 8 years ago

Are peerinfo objects authenticated? I am assuming each peerinfo object contains a map of services to multiaddresss. Does it also contain a signature on the corresponding map from the peer?

daviddias commented 8 years ago

Peers are authenticated when they perform the TLS like handshake between each other. That isn't audited yet but it will be.

PS: This question would fit the ipfs/faq repo best

wanderer commented 8 years ago

@diasdavid so in discovery you get a mappings of publicKey to peerinfo objects, correct? The attack I'm worried about is a malicious actor trying to poison the peer table. So it would start broadcasting know/trusted publicKeys but with bad endpoints.. possible with to endpoints it controlled. If the bad actor was an authoritarian regime it could use this to locate the ip all the nodes that trusted a given set of publicKeys.

The way to prevent this is not to broadcast publicKeys but to broadcast signature(peerObject): peerObject. And each node would derive the publicKey from the signature with the guarantee that only that id could have produced it

daviddias commented 8 years ago

@wanderer the solution you describe is what happens in the TLS/secio handshake, a challenge is created, a nounce has to be signed and only the node able to sign(nounce, privKey) that verify(signedNounce, pubKey) validates, is the owner of the key pair that leads to peer-Id QmABCDEFHASH. Note that the Id of a peer is always a multihash of its public key

wanderer commented 8 years ago

TLS/secio handshake

Right @diasdavid I'm not concerned about the actual connection here. I'm concerned about poisoning the peer table. An attacker may only want to locate peers. Not connect to them, so a failed handshake would be fine from the attacker's point of view.

But you can have verfication in the peer table. All you have to do though is add a signature to the peer routing/ peer table. so for example findPeers would give you a list of ids:endpoints that also contained a signature by the id (publickey). If you were a security focused node you might only have a whitelist of ids that you would connect to, therefore thwarting any attempt to reveal your IP by poising the peer table Does this make sense? Does this concern make sense?