Initial Commit
This commit is contained in:
commit
8aec5433fd
|
@ -0,0 +1 @@
|
||||||
|
book
|
|
@ -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/
|
|
@ -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>
|
|
@ -0,0 +1,6 @@
|
||||||
|
<?xml version="1.0" encoding="UTF-8"?>
|
||||||
|
<project version="4">
|
||||||
|
<component name="JavaScriptSettings">
|
||||||
|
<option name="languageLevel" value="ES6" />
|
||||||
|
</component>
|
||||||
|
</project>
|
|
@ -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>
|
|
@ -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>
|
|
@ -0,0 +1,6 @@
|
||||||
|
[book]
|
||||||
|
authors = ["Sarah Jamie Lewis"]
|
||||||
|
language = "en"
|
||||||
|
multilingual = false
|
||||||
|
src = "./src"
|
||||||
|
title = "Cwtch Secure Development Handbook"
|
|
@ -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)
|
|
@ -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)
|
||||||
|
|
|
@ -0,0 +1 @@
|
||||||
|
# Cwtch Library
|
|
@ -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.
|
|
@ -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.
|
|
@ -0,0 +1 @@
|
||||||
|
# Tapir
|
Loading…
Reference in New Issue