diff --git a/src/SUMMARY.md b/src/SUMMARY.md index f95842c..f213412 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -11,7 +11,9 @@ - [Groups](./groups.md) - [Cwtch UI](./ui.md) - [Profile Encryption & Storage](./profile_encryption_and_storage.md) -- [Cwtch Server](./server.md) + - [Android Service](./android.md) + - [Message Overlays](./overlays.md) +- [Cwtch Servers](./server.md) - [Development](./development.md) - [Deployment](./deployment.md) - [References](./references.md) diff --git a/src/android.md b/src/android.md new file mode 100644 index 0000000..2f4e193 --- /dev/null +++ b/src/android.md @@ -0,0 +1,3 @@ +# Android Service + +(Currently under active development, will be documented here once it has been merged into trunk) \ No newline at end of file diff --git a/src/authentication_protocol.md b/src/authentication_protocol.md index a77429f..bbb15ea 100644 --- a/src/authentication_protocol.md +++ b/src/authentication_protocol.md @@ -23,7 +23,7 @@ Once derived from the key derivation function \\(\mathrm{KDF}\\\) the key \\(k\\) is set *on* the connection, meaning the authentication app doesn't do the encryption or decryption explicitly. -Also the concatenation of parts of the 3DH exchange is strictly ordered: +The concatenation of parts of the 3DH exchange is strictly ordered: * DH of the Long term identity of the outbound connection by the ephemeral key of the inbound connection. diff --git a/src/cwtch.md b/src/cwtch.md index 2ec7344..f723eff 100644 --- a/src/cwtch.md +++ b/src/cwtch.md @@ -1,51 +1,30 @@ # Cwtch Library -# Known Risks - - -## Thread Safety - -**Status: Partially Mitigated (Work in Progress)** - -The Cwtch library evolved from a prototype that had weak checks around -concurrency and the addition of singleton behavior around saving profiles to -files and protocol engines resulted in race conditions. - -The inclusion of the `Event Bus` made handling such cases easier, and the -majority of the code is now tested via unit tests and integration test -running the `-race` flag. The last portion of the code that requires work in -this regard are around the AppBridge and Server which are used by the UI to -maintain separation. - ## Private information transiting the IPC boundary -**Status: Unmitigated (Requires privileged user to exploit)** +**Status: Requires privileged user to exploit** Information used to derive the encryption key used to save all sensitive data to the file system cross the boundary between the UI front-end and the App backend. Intercepting this information requires a privileged position on the local -machine. There are currently no plans to mitigate this issue. +machine. - - - ## Testing Status -Cwtch features one well-defined integration test which exercise the ideal case of +Cwtch features one [well-defined integration test](https://openprivacy.ca/discreet-log/06-cwtch-integ-tests/) which exercise the ideal case of three well-formed peers authenticating and messaging each other through an untrusted server. -In addition, unit tests are defined for a number of Cwtch modules, however - many of them have become outdated with the introduction of Tapir. - -Most tests are run with the `-race` flag which will cause them to fail if +Tests are run with the `-race` flag which will cause them to fail if race conditions are detected. Both integration tests and unit tests are run automatically for every pull request and main branch merge. ## Resolved or Outdated Risks + + ### Dependency on Outdated Protobuf Implementation **Status: Mitigated** @@ -75,4 +54,17 @@ against the server adjusting difficulty too often would also mitigate some of the more extreme vectors. Additionally, Token Based Services and Peer-based Groups are both potential - options for eliminating this attack vector entirely. \ No newline at end of file + options for eliminating this attack vector entirely. + +## Thread Safety + +**Status: Mitigated ** + +The Cwtch library evolved from a prototype that had weak checks around +concurrency, and the addition of singleton behavior around saving profiles to +files and protocol engines resulted in race conditions. + +The inclusion of the `Event Bus` made handling such cases easier, and the +code is now tested via unit tests and integration test +running the `-race` flag. + diff --git a/src/deployment.md b/src/deployment.md index 8a6c9e8..83ba9e3 100644 --- a/src/deployment.md +++ b/src/deployment.md @@ -3,17 +3,15 @@ ## Risk: Binaries are replaced on the website with malicious ones -**Status: Unmitigated** +**Status: Partially-mitigated** 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. +* Reproducible Builds - we currently use puplic docker containers for all builds + which should allow anyone to compare distributed builds with ones built from source. * 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 diff --git a/src/fuzzbot-invite.png b/src/fuzzbot-invite.png new file mode 100644 index 0000000..7f3dd1c Binary files /dev/null and b/src/fuzzbot-invite.png differ diff --git a/src/overlays.md b/src/overlays.md new file mode 100644 index 0000000..931a4dc --- /dev/null +++ b/src/overlays.md @@ -0,0 +1,57 @@ +# Message Overlays + +[Adapted from: Discreet Log #8: Notes on the Cwtch Chat API](https://openprivacy.ca/discreet-log/08-chatapi/) + +We envision Cwtch as a platform for providing an authenticated transport layer to higher-level applications. +Developers are free to make their own choices about what application layer protocols to use, +whether they want bespoke binary message formats or just want to throw an HTTP library on top and call it a +day. Cwtch can generate new keypairs for you (which become onion addresses; no need for any DNS registrations!) +and you can REST assured that any data your application receives from the (anonymous communication) +network has been authenticated already. + +For our current stack, messages are wrapped in a minimal JSON frame that adds +some contextual information about the message type. +And because serialised JSON objects are just dictionaries, we can easily add more metadata later on as needed. + + +## Chat overlays, lists, and bulletins + +The original Cwtch alpha demoed "overlays": different ways of interpreting the same data channel, +depending on the structure of the atomic data itself. W + +e included simple checklists and BBS/classified ads as overlays that could be viewed +and shared with any Cwtch contact, be it a single peer or a group. The wire format looked like this: + +``` +{o:1,d:"hey there!"} +{o:2,d:"bread",l:"groceries"} +{o:3,d:"garage sale",p:"[parent message signature]"} +``` + +Overlay field `o` determined if it was a chat (1), list (2), or bulletin (3) message. +The data field `d` is overloaded, and lists/bulletins need additional information about what +group/post they belong to. (We use message signatures in place of IDs to avoid things like message +ordering problems and maliciously crafted IDs. This is also how the Cwtch protocol communicates to the +front end which message is being acked.) + +## Data structure + +Implementing tree-structured data on top of a sequential message store comes with obvious +performance disadvantages. For example, consider the message view, which loads most-recent-messages first and only goes back far enough to fetch enough messages to fill the current viewport, in comparison with a (somewhat pathological) forum where almost every message is a child of the very first message in the history, which could have been gigs and gigs of data-ago. If the UI only displays top-level posts until the user expands them, we have to parse the entire history before we get enough info to display anything at all. + +Another problem is that multiplexing all these overlays into one data store creates "holes" in the data that confuse [lazy-loaded listviews](https://api.flutter.dev/flutter/widgets/ListView/ListView.builder.html) and scrollbars. The message count may indicate there is a ton more information to display if the user simply scrolls, but when it actually gets fetched and parsed we might realize that none of it is relevant to the current overlay. + +None of these problems are insurmountable, but they demonstrate a flaw in our initial assumptions about the nature of collaborative message flows and how we should be handling that data. + +## Invitations + +Instead of receiving the invite as an incoming contact request at the profile level, new inline invites are shared with a particular contact/group, where they can be viewed and/or accepted later, even if they were initially rejected (potentially by accident). + +The wire format for these are equally simple: + +``` +{o:100,d:"u4ypg7yyyrrvf2aceeclq5dgwtkirzletltbqofnb6km7u542qqk4jyd"} +{o:101,d:"torv3eyJHcm91cElEIjoiOWY3MWExYmFhNDkzNTAzMzAyZDFmODRhMzI2ODY2OWUiLCJHcm91cE5hbWUiOiI5ZjcxYTFiYWE0OTM1MDMzMDJkMWY4NGEzMjY4NjY5ZSIsIlNpZ25lZEdyb3VwSUQiOiJyVGY0dlJKRkQ2LzFDZjFwb2JQR0xHYzdMNXBKTGJTelBLRnRvc3lvWkx6R2ZUd2Jld0phWllLUWR5SGNqcnlmdXVRcjk3ckJ2RE9od0NpYndKbCtCZz09IiwiVGltZXN0YW1wIjowLCJTaGFyZWRLZXkiOiJmZVVVQS9OaEM3bHNzSE9lSm5zdDVjNFRBYThvMVJVOStPall2UzI1WUpJPSIsIlNlcnZlckhvc3QiOiJ1cjMzZWRid3ZiZXZjbHM1dWU2anBrb3ViZHB0Z2tnbDViZWR6ZnlhdTJpYmY1Mjc2bHlwNHVpZCJ9"} +``` + +This represents a departure from our original "overlays" thinking to a more action-oriented representation. The chat "overlay" can communicate that someone *did* something, even if it's paraphrased down to "added an item to a list," and the lists and bulletins and other beautifully chaotic data can have their state precomputed and stored separately. diff --git a/src/overview.md b/src/overview.md index f621832..62abe58 100644 --- a/src/overview.md +++ b/src/overview.md @@ -1,6 +1,6 @@ # Overview -Welcome to the Cwtch Secure Development Handbook. The purpose of this +Welcome to the Cwtch Secure Development Handbook! The purpose of this handbook is to provide a guide to the various components of the Cwtch ecosystem, to document the known risks and mitigations, and to enable discussion about improvements and updates to Cwtch secure development @@ -9,7 +9,7 @@ processes. ![](https://docs.openprivacy.ca/cwtch-security-handbook/2.png) -## History +## A (Brief) History of Metadata Resistant Chat In recent years, public awareness of the need and benefits of end-to-end encrypted solutions has increased with applications like [Signal](https://signalapp.org), @@ -20,20 +20,42 @@ However, these tools require various levels of metadata exposure to function, and much of this metadata can be used to gain details about how and why a person is using a tool to communicate. [[rottermanner2015privacy]](https://www.researchgate.net/profile/Peter_Kieseberg/publication/299984940_Privacy_and_data_protection_in_smartphone_messengers/links/5a1a9c29a6fdcc50adeb1335/Privacy-and-data-protection-in-smartphone-messengers.pdf). -One tool that does seek to reduce metadata is [Ricochet](https://ricochet.im) first released in 2014. -Ricochet uses Tor onion services to provide secure end-to-end encrypted communication, +One tool that did seek to reduce metadata is [Ricochet](https://ricochet.im) first released in 2014. +Ricochet used Tor v2 onion services to provide secure end-to-end encrypted communication, and to protect the metadata of communications. -There are no centralized servers that assist in routing Ricochet -conversations. No one other than the parties involved in a conversation can +There were no centralized servers that assist in routing Ricochet +conversations. No one other than the parties involved in a conversation could know that such a conversation is taking place. -Ricochet isn't without limitations; there is no multi-device support, nor is -there a mechanism for supporting group communication or for a user to send -messages while a contact is offline. +Ricochet wasn't without limitations; there was no multi-device support, nor is +there a mechanism for supporting group communication or for a user to send +messages while a contact is offline. -This makes adoption of Ricochet a difficult proposition; with even those in -environments that would be served best by metadata resistance unaware that it +This made adoption of Ricochet a difficult proposition; with even those in +environments that would be served best by metadata resistance unaware that it exists [[ermoshina2017can]](www.academia.edu/download/53192589/ermoshina-12.pdf) [[renaud2014doesn]](https://eprints.gla.ac.uk/116203/1/116203.pdf). +Additionally, any solution to decentralized, metadata resistant communication faces [fundamental problems](https://code.briarproject.org/briar/briar/-/wikis/Fundamental-Problems) +when it comes to efficiency, privacy and group security (as defined by [transcript consensus and consistency](https://code.briarproject.org/briar/briar/-/wikis/Fundamental-Problems)). + +Modern alternatives to Ricochet include [Briar](https://briarproject.org), [Zbay](https://www.zbay.app/) +and [Ricochet Refresh](https://www.ricochetrefresh.net/) - each tool seeks to optimize for a different +set of trade-offs e.g. Briar seeks to allow people to communicate [even when underlying network infrastructure +is down](https://briarproject.org/how-it-works/) while providing resistant to metadata surveillance. + +