From cb7c4c7dd74d6a2dd5a0457c93d4934784963427 Mon Sep 17 00:00:00 2001 From: Sarah Jamie Lewis Date: Tue, 23 Jun 2020 12:05:07 -0700 Subject: [PATCH] Server and Development Stubs. --- src/SUMMARY.md | 5 +++ src/deployment.md | 1 + src/development.md | 38 ++++++++++++++++++++++ src/groups.md | 1 + src/server.md | 79 ++++++++++++++++++++++++++++++++++++++++++++++ 5 files changed, 124 insertions(+) create mode 100644 src/deployment.md create mode 100644 src/development.md create mode 100644 src/groups.md create mode 100644 src/server.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index ecc5e95..32df8ae 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -5,4 +5,9 @@ - [Connectivity](./connectivity.md) - [Tapir](./tapir.md) - [Cwtch Library](./cwtch.md) + - [Groups](./groups.md) - [Cwtch UI](./ui.md) +- [Cwtch Server](./server.md) +- [Development](./development.md) +- [Deployment](./deployment.md) + diff --git a/src/deployment.md b/src/deployment.md new file mode 100644 index 0000000..d36c65e --- /dev/null +++ b/src/deployment.md @@ -0,0 +1 @@ +# Deployment diff --git a/src/development.md b/src/development.md new file mode 100644 index 0000000..b73b433 --- /dev/null +++ b/src/development.md @@ -0,0 +1,38 @@ +# Development + +The main process to counter malicious actors in development of Cwtch is the +openness of the process. + +To enhance this openness, automated builds, testing and packaging are defined +as part of the repositories - improving te robustness of the code base at every +stage. + +While individual tests aren't perfect, and all processes have gaps, we should be +committed to make it as easy as possible to contribute to Cwtch while also + building pipelines and processes that catch errors (unintential or malicious) + as soon as possible. + +### Risk: Developer Directly Pushes Malicious Code + +**Status: Mitigated** + +Master is currently locked and 3 Open Privacy staff members have permission +to override it, and the responsibility of monitoring changes. + +Further every new pull request and merge triggered automated builds & tests + which trigger emails and audit logs. + +The code is also open source and inspectable by anyone. + +### Risk: Code Regressions + +**Status: Partially Mitgated** (See individual project entries in this + handbook for more information) + +Our automated pipelines have the ability to catch regressions when that + behaviour is detectable. + +The greatest challenge is in defining how such regressions are detected for the +[ui](./ui.md) - where behaviour isn't as strictly defined as it is for the + individual libraries. + \ No newline at end of file diff --git a/src/groups.md b/src/groups.md new file mode 100644 index 0000000..e97b3e9 --- /dev/null +++ b/src/groups.md @@ -0,0 +1 @@ +# Groups diff --git a/src/server.md b/src/server.md new file mode 100644 index 0000000..af4d4b7 --- /dev/null +++ b/src/server.md @@ -0,0 +1,79 @@ +# Cwtch Server + +The goal of the Cwtch protocol is to enable group communication through +**Untrusted Infrastructure**. + +Unlike in relay-based schemes where the groups assign a leader, set of + leaders, or a trusted third party server to ensure that every member of the + group can send and receive messages in a timely manner (even if members are + offline) - untrusted infrastructure has a goal of realizing those properties + without the assumption of trust. + +The orignal Cwtch paper defined a set of properties that Cwtch Servers were +expected to provide: + +* Cwtch Server may be used by multiple groupsor just one. +* A Cwtch Server, without collaboration of a group member, should + never learn the identity of participants within a group. +* A Cwtch Server should never learn the content of any communication. +* A CwtchServer should never be able to distinguish messages as belonging + to a particular group. + +We note here that these properties are a superset of the design aims of Private +Information Retrieval structures. + +## Malcious Servers + +We expect the presence of malicious entities within the Cwtch ecosystem. + +We also prioritize decentralization and permissionless entry into the + ecosystem and as such we do not base any security claims on the following: + +* Any non-collusion assumptions between a set of Cwtch servers +* Any third-party defined verification process + +Peers themselves are encouraged to set up and run Cwtch servers where they can +guarantee more efficient properties by relaxing trust and security + assumptions - however, by default, we design the protocol to be secure without + these assumptions - sacrificing efficiency where necessary. + +### Detectable Faults + +* If a Cwtch server fails to relay a specific message to a subset of group + members then there will be a detectable gap in the message tree of certain + peers that can be discovered through peer-to-peer gossip. +* A Cwtch server cannot modify any message without the key material known to +the group (any attempt to do so for a subset of group memebers will result in +identical behavior to failing to relay a message). +* While a server *can* duplicate messages, these will have no impact on the + group message tree (because of encryption, nonces and message identities + ) - the source of the duplication is not knowable to a peer. + +## Efficiency + +As of writing, only 1 protocol is known for achieving the desired properties, +naive PIR or "the server sends everything, and the peers sift through it". + +This has an obvious impact on bandwidth efficiency, especially for peers using +mobile devices, as such we are actively developing new protocols in which the +privacy and efficiency guarantees can be traded-off in different ways. + +The most developed idea is to bucket the messages on the server into discrete +time windows and allow peers to fetch smaller batches, coupled with the + underlying tor connection this technique should provide sufficient privacy + - although the technique still needs formal verification. + +# Protecting the Server from Malicious Peers + +The main risk to servers come in the form of spam generated by peers. In the +prototype of Cwtch a spamguard mechanism was put in place that required +peers to conduct some arbitrary proof of work given a server-specified + parameter. + +This is not a robust solution in the presence of a determined adversary with +a significant amount of resources, and thus one of the main external risks to + the Cwtch system becomes censorship-via-resource exhaustion. + +We have outlined a potential solution to this in +[token based services](https://openprivacy.ca/research/OPTR2019-01/) but note + that this also requires further development.