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