2.9 KiB
Practical Client-side Replication: Weak Consistency Semantics for Insecure Settings
Authors: van der Linde, Leitao, Preguica
Definition
causal consistency: model enforcing clients to observe a state that respects the causal order of operations. (this is the case for decentralized and peer to peer systems)
Attacks on causal consistency:
- Tempering: a node submit an operation to anticipate a pending operation actually not yet executed by the system.
- Omitting dependencies: a node used only a subset of the operations in the dependency. He will be able to submit a concurrent task to the system.
- Unseen dependencies (also called add): a node submit an operation that depends on an operation that he didn't see. It can be usefull for the attacker to anticipate the operation. (This is different from tempering because in this case the operation does not exist yet).
- Combining omitting and unseen: a node can omit a dependency and submit an operation that depends on an operation that he didn't see.
- Sibbling generation: creating two differents operations with the same id. The attacker could create a permanent state divergence between the nodes.
Summary
Solutions used in the paper
Secure Causal Consistency
Autors defined the properties of a secure causal consistency: Immutable History, No Future Dependencies, Causal Executions, Limitted Omission, and Eventual Sibling Detection.
The algorithms they propose used the following solutions for each property:
- Immutable History: The nodes sign the operations and the dependencies. The nodes can't temper the history because they can't sign the operation.
- No Future Dependencies: Each operations includes a hash of all direct causal dependencies. The nodes can't omit dependencies because they can't sign the operation.
- Causal Executions: The nodes need to verify, before executing an operation, that all the dependencies are executed.
- Limitted Omission: It's by design impossible due to the metadata (hash of the dependencies).
- Eventual Sibling Detection: Many mechanism are used:
- a node is able to detect when two operations with the same id are send from differents paths.
- a node is able than the hash of the dependencies is different with the hash provide by the operation.
- the nodes are comparing the dependencies of the operation between them. If they are different, they are able to detect the sibbling generation.
Secure Strict Causal Consistency
The Secure Strict Causas Consistency is a variant of the Secure Causal Consistency who is using a trusted service. Such as the enclave in Intel SGX. Thus the usage of a hash of the dependencies is unnecessary. An issue of this solution is the cost of the connection to the trusted service. A possible attack would be to connect and disconnect a lot of time of the trusted service to make the system slow. This sollution was not explored in the paper due to this issue.