groups, deployment and servers
This commit is contained in:
parent
cb7c4c7dd7
commit
4a6916732e
|
@ -10,4 +10,5 @@
|
|||
- [Cwtch Server](./server.md)
|
||||
- [Development](./development.md)
|
||||
- [Deployment](./deployment.md)
|
||||
- [References](./references.md)
|
||||
|
||||
|
|
|
@ -1 +1,21 @@
|
|||
# Deployment
|
||||
|
||||
|
||||
## Risk: Binaries are replaced on the website with malicious ones
|
||||
|
||||
**Status: Unmitigated**
|
||||
|
||||
While this process is now mostly automated, should this automation ever be
|
||||
compromised then there is nothing in our current process that would detect this.
|
||||
|
||||
We need:
|
||||
|
||||
* Reproducible Builds - it is unlikely that we will be able to do this
|
||||
overnight, several parts of our build process (Qt builds, the recipe etc.)
|
||||
may introduce non-determinism. Nevertheless, we should seek to identify where
|
||||
this non-determinism is.
|
||||
* Signed Releases - Open Privacy does not yet maintain a public record of staff
|
||||
public keys. This is likely a necessity for signing released builds and
|
||||
creating an audit chain backed by the organization. This process must be
|
||||
manual by definition.
|
||||
|
||||
|
|
|
@ -1 +1,60 @@
|
|||
# Groups
|
||||
|
||||
For the most part the Cwtch risk model for groups is split into two distinct
|
||||
profiles:
|
||||
|
||||
* Groups made up of mutually trusted participants where peers are assumed
|
||||
honest.
|
||||
* Groups consisting of strangers where peers are assumed to be potentially
|
||||
malicious.
|
||||
|
||||
Most of the mitigations described in this section relate to the latter case, but
|
||||
naturally also impact the former. Even if assumed honest peers later turn
|
||||
malicious there are mechanisms that can detect such malice and prevent it from
|
||||
happening in the future.
|
||||
|
||||
## Risk Overview: Key Derivation
|
||||
|
||||
In the ideal case we would use a protocol like OTR, the limitations preventing
|
||||
us from doing so right now are:
|
||||
|
||||
* Offline messages are not guaranteed to reach all peers, and as such any
|
||||
metadata relating to key material might get lost. We need a key derivation
|
||||
process which is robust to missing messages or incomplete broadcast.
|
||||
|
||||
## Risk: Malicious Peer Leaks Group Key and/or Conversation
|
||||
|
||||
**Status: Partially Mitigated (but impossible to mitigate fully)**
|
||||
|
||||
Whether dealing with trusted smaller groups or partially-public larger groups
|
||||
there is *always* the possibility that a malicious actor will leak group
|
||||
messages.
|
||||
|
||||
We plan to make it easy for peers to [fork](#fork) groups to mitigate the
|
||||
same key being used to encrypt lots of sensitive information and provide
|
||||
some level of forward secrecy for past group conversations.
|
||||
|
||||
## Risk: Active Attacks by Group Members
|
||||
|
||||
**Status: Partially Mitigated**
|
||||
|
||||
Group members, who have access to the key material of the group, can conspire
|
||||
with a server or other group members to break transcript consistency.
|
||||
|
||||
While we cannot directly prevent censorship given this kind of active
|
||||
collusion, we have a number of mechanisms in place that should reveal the
|
||||
presence of censorship to honest members of the group.
|
||||
|
||||
### Mitigations:
|
||||
|
||||
* Because each message is signed by the peers public key, it should not be
|
||||
possible (within the cryptographic assumptions of the underlying cryptography)
|
||||
for one group member to imitate another.
|
||||
* Each message contains a unique identifier derived from the contents and the
|
||||
previous message hash - making it impossible for collaborators to include
|
||||
messages from non-colluding members without revealing an implicit message
|
||||
chain (which if they were attempting to censor other messages would
|
||||
reveal such censorship)
|
||||
|
||||
Finally: We are actively working on adding non-repudiation to Cwtch servers such
|
||||
that they themselves are restricted in what they can censor efficiently.
|
|
@ -0,0 +1,6 @@
|
|||
# References
|
||||
|
||||
* Nik Unger et al. “SoK: secure messaging”. In:Security and Privacy (SP
|
||||
), 2015 IEEE Sympo-sium on. IEEE. 2015, pp. 232–249 [link](http://cacr.uwaterloo.ca/techreports/2015/cacr2015-02.pdf)
|
||||
|
||||
|
|
@ -60,8 +60,8 @@ 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.
|
||||
underlying tor connection this technique should provide sufficient privacy -
|
||||
although the technique still needs formal verification.
|
||||
|
||||
# Protecting the Server from Malicious Peers
|
||||
|
||||
|
|
Loading…
Reference in New Issue