Initial Commit

This commit is contained in:
Sarah Jamie Lewis 2020-06-17 14:49:52 -07:00
commit 8aec5433fd
14 changed files with 188 additions and 0 deletions

1
.gitignore vendored Normal file
View File

@ -0,0 +1 @@
book

8
.idea/.gitignore vendored Normal file
View File

@ -0,0 +1,8 @@
# Default ignored files
/shelf/
/workspace.xml
# Datasource local storage ignored files
/dataSources/
/dataSources.local.xml
# Editor-based HTTP Client requests
/httpRequests/

View File

@ -0,0 +1,8 @@
<?xml version="1.0" encoding="UTF-8"?>
<module type="WEB_MODULE" version="4">
<component name="NewModuleRootManager">
<content url="file://$MODULE_DIR$" />
<orderEntry type="inheritedJdk" />
<orderEntry type="sourceFolder" forTests="false" />
</component>
</module>

6
.idea/misc.xml Normal file
View File

@ -0,0 +1,6 @@
<?xml version="1.0" encoding="UTF-8"?>
<project version="4">
<component name="JavaScriptSettings">
<option name="languageLevel" value="ES6" />
</component>
</project>

8
.idea/modules.xml Normal file
View File

@ -0,0 +1,8 @@
<?xml version="1.0" encoding="UTF-8"?>
<project version="4">
<component name="ProjectModuleManager">
<modules>
<module fileurl="file://$PROJECT_DIR$/.idea/cwtch-security-book.iml" filepath="$PROJECT_DIR$/.idea/cwtch-security-book.iml" />
</modules>
</component>
</project>

6
.idea/vcs.xml Normal file
View File

@ -0,0 +1,6 @@
<?xml version="1.0" encoding="UTF-8"?>
<project version="4">
<component name="VcsDirectoryMappings">
<mapping directory="$PROJECT_DIR$" vcs="Git" />
</component>
</project>

6
book.toml Normal file
View File

@ -0,0 +1,6 @@
[book]
authors = ["Sarah Jamie Lewis"]
language = "en"
multilingual = false
src = "./src"
title = "Cwtch Secure Development Handbook"

8
src/SUMMARY.md Normal file
View File

@ -0,0 +1,8 @@
# Summary
- [Overview](./overview.md)
- [Risk Model](./risk.md)
- [Connectivity](./connectivity.md)
- [Tapir](./tapir.md)
- [Cwtch Library](./cwtch.md)
- [Cwtch UI](./ui.md)

64
src/connectivity.md Normal file
View File

@ -0,0 +1,64 @@
# Connectivity
Cwtch makes use of Tor Onion Services (v3) for all inter-node communication.
We provide the [openprivacy/connectivity](https://git.openprivacy.ca/openprivacy/connectivity)
package for managing the Tor daemon and setting up and tearing down onion
services through Tor.
## Known Risks
### Private Key Exposure to the Tor Process
**Status: Unmitigated** (Requires Physical Access or Privilege Escalation to
exploit)
We must pass the private key of any onion service we wish to set up to the
connectivity library, through the `Listen` interface (and thus to the Tor
process). This is one of the most critical areas that is outside of our
control. Any binding to a rouge tor process or binary will result in
compromise of the Onion private key.
#### Potential Mitigations
We should not attempt to bind to the system-provided Tor process as the default,
unless we have been provided with an authentication token.
Otherwise we should always attempt to deploy our own Tor process using a known
good binary packaged with the syste (outside of the scope of the connectivity
package)
In the long term we hope an integrated library will become available and allow
direct management through an in-process interface to prevent the private key
from leaving the process boundary (or other alternative paths that allow us
to maintain full control over the private key in-memory.)
### Tor Process Management
**Status: Partially Mitigated** (Requires Physical Access or Privilege
Escalation to exploit)
Many issues can arise from the management of a separate process, including the
need to restart, exit and otherwise ensure appropriate management.
The [ACN](https://git.openprivacy.ca/openprivacy/connectivity/src/branch/master/acn.go)
interface provides `Restart`, `Close` and `GetBootstrapStatus` interfaces to
allow applications to manage the underlying Tor process. In addition the `SetStatusCallback`
method can be used to allow an application to be notified when the status of
the Tor process changes.
However, if sufficiently-privileged users wish they can interfere with this
mechanism, and as such the Tor process is a more brittle component
interaction than others.
These mechanisms need to be documented.
## Testing Status
Current connectivity has limited unit testing capabilities and none of these
are run during pull requests or merges. There is no integration testing.
It is worth noting that connectivity is used by both Tapir and Cwtch in their
integration tests (and so despite the lack of package level testing, it is
exposed to system-wide test conditions)

1
src/cwtch.md Normal file
View File

@ -0,0 +1 @@
# Cwtch Library

7
src/overview.md Normal file
View File

@ -0,0 +1,7 @@
# Overview
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
processes.

63
src/risk.md Normal file
View File

@ -0,0 +1,63 @@
# Risk Model
Communications metadata is known to be exploited by various adversaries to
undermine the security of systems, to track victims
and to conduct large scale social network analysis to feed mass surveillance.
Metadata resistant tools are in their infancy and research into the construction
and user experience of such tools is lacking.
Cwtch was originally concieved an extension of the metadata resistant protocol
Ricochet to support asynchronous, multi-peer group communications through the
use of discardable, untrusted, anonymous infrastructure.
Since then, Cwtch has evolved into a protocol in its own right, this section
will outline the various known risks that Cwtch attempts to mitigate and will
nbe heavily referenced throughout the rest of the document when discussing the
various sub-components of the Cwtch Architecture.
## Threat Model
It is important to identify and understand that metadata is ubiquitous in
communication protocols, it is indeed necessary for such protocols to
function efficiently and at scale. However, information that is useful to
facilitating peers and servers is also highly relevant to adversaries
wishing to exploit such information.
For our problem definition, we will assume that the content of a communication is
encrypted in such a way that an adversary is practically unable to break
(see [tapir](./tapir.md) and [cwtch](./cwtch.md) for details on the
encryption that we use, a
and as such we will focus to the context to the communication metadata.
We seek to protect the following communication contexts:
* Who is involved in a communication? It may be possible to identify
people or simply device or network identifiers. E.g., “this communication involves Alice, a journalist, and Bob a government employee.”.
* Where are the participants of the conversation? E.g., “during this
communication Alice was in France and Bob was in Canada.”
* When did a conversation take place? The timing and length of communication
can reveal a large amount about the nature of a call, e.g., “Bob a government employee, talked to Alice on the phone for an hour yesterday evening. This is the first time they have communicated.”
*How was the conversation mediated? Whether a conversation took place over an
encrypted or unencrypted email can provide useful intelligence. E.g., “Alice sent an encrypted email to Bob yesterday, whereas they usually only send plaintext emails to each other.”
* What is the conversation about? Even if the content of the communication is
encrypted it is sometimes possible to derive a probable context of a conversation without knowing exactly what is said, e.g. “a person called a pizza store at dinner time” or “someone called a known suicide hotline number at 3am.”
Beyond individual conversations, we also seek to defend against context correlation attacks, whereby multiple conversations are analyzed to derive higher level information:
* Relationships: Discovering social relationships between a pair of entities
by analyzing the frequency and length of their communications over a period of time. E.g. Carol and Eve call each other every single day for multiple hours at a time.
* Cliques: Discovering social relationships between a group of entities that
all interact with each other. E.g. Alice, Bob and Eve all communicate with each other.
* Loosely Connected Cliques and Bridge Individuals: Discovering groups that
communicate to each other through intermediaries by analyzing communication chains (e.g. everytime Alice talks to Bob she talks to Carol almost immediately after; Bob and Carol never communicate.)
* Pattern of Life: Discovering which communications are cyclical and
predictable. E.g. Alice calls Eve every Monday evening for around an hour.
## A note on Physical Attacks
Cwtch does not consider attacks that require physical access (or equivalent) to
the users machine as practically defendable. However, in the interests of good
security engineering, throughout this document we will still
refer to attacks or conditions that require such privilege and point out
where any mitigations we have put in place will fail.

1
src/tapir.md Normal file
View File

@ -0,0 +1 @@
# Tapir

1
src/ui.md Normal file
View File

@ -0,0 +1 @@
# Cwtch UI