Open borzunov opened 3 years ago
The protocol is partially implemented in #255 to protect the DHT service. This partially protects other services (e.g. averager) since peer endpoints for these services are fetched from the DHT.
The next task is to implement the protocol for the averager and other services. This would protect from replay and MITM attacks on these services performed with fake stateful requests.
@borzunov can we consider this done?
Not completely, see the comment above (some technically harder attacks involving fake stateful requests to averager are still possible). Previously, the task was blocked by implementing the averager over libp2p. Now, I see two options:
We consider a moderated decentralized deep learning experiment. To join, a new participant is required to register on a website providing a login, a password, and information about themself. Moderators can review the information and authorize the participant to join the Hivemind network. Later, if they observe malicious actions from the participant, they can withdraw their authorization and roll back the model and the DHT state (if needed).
This issue proposes an authorization protocol for Hivemind peers to interact with each other without the constant need to confirm another peer's authorization with a central server. The protocol is intended to be secure against eavesdropping and man-in-the-middle attacks.
1. Introduction
We assume to have of a central authorization server. It owns a key pair
(auth_server_public_key, auth_server_private_key)
. Peers have a secure communication channel with this server (e.g. the server use HTTPS or TLS).Also, we assume each peer to have their own key pair
(peer_public_key, peer_private_key)
. We can't assume that peers have secure communication channels between each other (like TLS) since it is impractical for each peer to get the approval of a certificate authority.Every time a peer provides its endpoint on the network (e.g. when adding itself to the DHT routing table), it should also provide its
peer_public_key
. (implementation detail: with libp2p, the endpoint and the public key may be united to one entity)2. Joining the network
peer_public_key
to the authorization server.peer_public_key
was not used by somebody else.expiration_time
(e.g. for 6 hours) and responds to the peer with:hivemind_access_token
- the tuple(peer_public_key, expiration_time)
signed withauth_server_private_key
. For other peers, this token will mean that the peer withpeer_public_key
has been granted access to the Hivemind network untilexpiration_time
.auth_server_public_key
- the server's public key. This is to allow the peer to check the access tokens of other peers.bootstrap_nodes
- a list of tuples(endpoint, public_key)
for peers who recently joined the network. This is to tell the peer where it can start joining the network (e.g. see how Bitcoin nodes initially find peers).During the joining procedure, HTTPS/TLS protect us from eavesdropping and man-in-the-middle.
3. Making requests
If Alice wants to make a request to Bob, the request content is extended with a structure with the following fields:
alice_access_token
(includesalice_public_key
inside)bob_public_key
current_time
nonce
- a random bytes that are supposed to be unique for each request (similar to nonce in OAuth 1.0)signature
- a signature of the request content and the fields above made withalice_private_key
Bob should store all
request_id
s for request accepted in the last N seconds. Also, Bob should reject all requests where:alice_access_token
is invalid or expiredsignature
is invalid w.r.t.alice_public_key
nonce
is the same as one of the nonces he storescurrent_time
differs from his time by more than N secondsbob_public_key
differs from his actual public keyThis way, Bob ensures that:
Note that an eavesdropped request can't be replayed to anybody, and a man-in-the-middle attacker can't replace the request content.
4. Responding to requests
When Bob responds to Alice, the response content is extended with a structure with the following fields:
bob_access_token
nonce
that identifies the requestsignature
of the response content and the fields above made withbob_private_key
Alice should reject the response if:
bob_access_token
is invalid or expiredbob_public_key
insidebob_access_token
matches the expectedbob_public_key
nonce
doesn't match the requestnonce
signature
is invalid w.r.t.bob_public_key
This way, Alice ensures that:
nonce
Note that an eavesdropped response can't be replayed for another request, and a man-in-the-middle attacker can't replace the response content.
5. Banning peers faster (optional)
The authorization server may also issue messages
('ban', peer_public_key)
signed with theauth_server_private_key
. Such messages may be propagated by the peers, and the peers can stop interacting with the banned peers.