Keep is a decentralized network that is anchored to one or more host chains via on-chain smart contracts, allowing interactions both on- and off-chain depending on the use case. To ensure the safety, security, and integrity of the network, the network needs to implement authorization, encryption, and authentication. The decentralized nature of the network brings about the unique challenge where off-the-shelf protocols (such as TLS) aren’t suitable. Specifically, these protocols can’t be used as-is due to their requirement of trusted central authorities and intermediaries. That being said, with some modifications, we can make these options more secure and work for our use case.
This document specifies the desired behaviors and properties of a protocol that will secure the network layer of Keep.
A successful protocol involves verifying identities (to prevent Sybil attacks), ensuring message integrity (to avoid malicious tampering), and allows for the encrypting of messages (to ensure that only intended recipients receive a message). Furthermore, the protocol should be versioned for easy upgrades.
- peer
-
A member of a network that can initiate, accept, and handle secure connections.
- network
-
A set of peers who are connected to each other, not necessarily p2p.
- chain
-
A decentralized, consensus driven store with identities and economic incentives.
- stake
-
The amount of value a given participant has locked up for participation in the network. This value is held on the host chain, and always associated with an identity.
- minimum stake
-
The minimum amount of value that is required to be a participant in the network.
- bootstrap peer
-
An authenticated peer that handles requests for joining the network from unauthenticated peers. This involves verifying an on-chain stake among many other responsibilities.
We aim to authenticate peers, control access to a network where Keep’s protocols execute, and provide verifiable private channels between communicating peers.
First and foremost, the protocol should be secure.
[AAKE] introduces us to the definition of a secure protocol; summarized:
-
If two peers, P1 and P2, share a secret key, it is computationally infeasible for anyone other than P1 and P2 to recover that secret key. Both peers can unlock the whole communication, but no other peers can understand the communication unless one of the peers chooses to unlock the communication.
-
The record of messages shared between P1 and P2 to establish the authentication of identity must be identical, within a given session, regardless of perspective and logically linked (from one message to the next).
These constraints prevent replay attacks (re-use of previous messages) and interleaving attacks (injecting a message used in previous runs).
In addition to being a secure protocol, the protocol must also provide the following capabilities:
The goal of authentication is to provide the communicating parties with some assurance that they know each others' identities.
An authenticated peer is a known identity in the network such that all messages from the authenticated peer, Pi, can be provably linked to Pi.
Given an authenticated peer and an unauthenticated peer, the unauthenticated peer must provide the authenticated peer proof of ownership of an on-chain identity with an associated stake. If an authenticated peer’s stake falls below the minimum stake for any reason, then an authenticated peer becomes unauthenticated.
The goal of authorization is to ensure that capabilities within the system are restricted to authenticated identities.
The only capabilities unauthenticated peers have are sending an initialization message to bootstrap peers.
Bootstrap peers are authenticated peers that accept connections from unauthenticated peers and attempt to authenticate those peers.
Authenticated peers can send and accept all kinds of messages.
Further access and capabilities are restricted by the individual protocols.
A secure protocol that is capable of authenticating and authorizing peers should also guarantee integrity, attributability, and (optionally) confidentiality.
A protocol that enforces integrity is one in which data sent over the network by authenticated peers cannot be modified by adversaries without detection.
Attributability enforces that a message from a given peer is known to be from that peer.
Furthermore, successful attributability requires replay protection (which implies message ordering enforcement). Consider the following case: an insecure scheme would allow an adversary to intercept the communications between two peers, modify the contents of a message (particularly of a message that has already been received and processed by the receiving peer), and continue forwarding the communication off to the receiving end. A receiver with an improper implementation would process this message like any other, believing it was from the intended sender. This would allow the adversary to forge communications with a unsuspecting recipient as if they were the sender!
Our protocol optionally provides confidentiality, where a message sent from an authenticated peer is only intelligible to the communicating, authenticated peers.
The protocol should be able to satisfy some known scenarios, described below, though this should not be considered a comprehensive list.
An unauthenticated peer wants to become an authenticated peer in the Keep Network. This peer must be, first and foremost, successfully staked (otherwise dishonest participants can’t be punished). Furthermore, the peer must prove their stake to the members of the network.
The authentication and authorization capabilities cover the requirements of this example. Specifically, authentication allows a peer to validate the identity of the unknown peer. Authorization enables the following:
-
The restriction of the unknown, untrusted peer to only send the initial request to be authenticated.
-
The capability of an authenticated peer to respond to on-chain events or to network-specific events.
-
The disconnection from the network for members who fall below the minimum stake.
A peer wishes to send a point-to-point message such that only the intended recipient can inspect and verify the contents of the message.
This example presumes that the identity is verified and accepted in the network, which means that authentication and authorization are satisfied. Confidentiality is needed to ensure that the communicating peers can communicate in secret. Integrity ensures that the message hasn’t been tampered with in transit over the wire. Attributability ensures that if either peer sends a message which contains a payload that would result in punishment, the correct peer will be punished.
Given the above, we are primarily concerned with authentication and key exchange. The literature overwhelmingly recommends a solution which provides authentication and key-exchange considered jointly. Per [AAKE]:
A protocol providing authentication without key exchange is susceptible to an enemy who waits until the authentication is complete and then takes over one end of the communications line. Such an attack is not precluded by a key exchange that is independent of authentication. Key exchange should be linked to authentication so that a party has assurances that an exchanged key (which might be used to facilitate privacy or integrity and thus keep authenticity alive) is in fact shared with the authenticated party, and not an impostor. For these reasons, it is essential to keep key exchange in mind in the design and analysis of authentication protocols.
Our system has two levels of key exchange:
-
An out-of-band process for confirming an on-chain identity (is the peer attempting to join the network staked).
-
Ephemeral key exchange for the purposes of authenticating in-network identities and sending confidential messages (is the peer sending this message really who they say they are).
-
Is a requirement for communicating participants that they be online?
-
Should all communications between Keep nodes be encrypted in order to provide confidentiality for all transcripts between nodes?
-
[AAKE] Diffie W. (1992) Authentication and Authenticated Key Exchanges In: Designs, Codes and Cryptography, 2, 107-125 (1992), Kluwer Academic Publishers http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.216.6107&rep=rep1&type=pdf
-
Discussions on writing this document:
-
t-ECDSA performance with some thoughts on network performance optimizations: https://www.flowdock.com/app/cardforcoin/tech/messages/154946
-
Desired properties of confidentiality in Keep’s network: https://www.flowdock.com/app/cardforcoin/tech/messages/156769