|
|
|
|
@ -41,7 +41,7 @@ as Data Minimization, End-to-End and Interoperability in order to
|
|
|
|
|
enable access to Human Rights. While (partial) implementations of
|
|
|
|
|
these concepts are already available, today's applications widely lack
|
|
|
|
|
Privacy support that ordinary users can easily handle.
|
|
|
|
|
This document covers use cases, anaysis of threats and requirements.
|
|
|
|
|
This document covers use cases, analysis of threats and requirements.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
--- middle
|
|
|
|
|
@ -57,7 +57,7 @@ Privacy support that ordinary users can easily handle.
|
|
|
|
|
In MEDUP these issues are addressed based on Opportunistic Security
|
|
|
|
|
{{RFC7435}} principles.
|
|
|
|
|
|
|
|
|
|
This document describes the use cases, contains an anaysis of threats
|
|
|
|
|
This document describes the use cases, contains an analysis of threats
|
|
|
|
|
and deduces the requirements.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@ -70,7 +70,7 @@ and deduces the requirements.
|
|
|
|
|
{::include ../shared/text-blocks/mitm.mkd}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# Movitation and Background
|
|
|
|
|
# Motivation and Background
|
|
|
|
|
|
|
|
|
|
To achieve privacy of exchanged messages in an opportunistic way
|
|
|
|
|
{{RFC7435}}, the following model (simplified) is proposed by pEp (pretty Easy
|
|
|
|
|
@ -78,29 +78,76 @@ Privacy) {{I-D.birk-pep}}:
|
|
|
|
|
|
|
|
|
|
{::include ../shared/ascii-arts/basic-msg-flow.mkd}
|
|
|
|
|
|
|
|
|
|
pEp is using the paradigm to have online and offline transports.
|
|
|
|
|
|
|
|
|
|
On offline transport is transporting messages by store and forward. The
|
|
|
|
|
connection status of the receiver is not important while sending, and it
|
|
|
|
|
may be not available at all. Examples are Internet Mail and SMS.
|
|
|
|
|
|
|
|
|
|
An online transport is transporting messages synchronously to receivers
|
|
|
|
|
if those are online. If receivers are offline, no message can be
|
|
|
|
|
transported. The connection status of an receiver is available to the
|
|
|
|
|
sender. Examples are Jabber and IRC.
|
|
|
|
|
|
|
|
|
|
pEp is supposed to solve three problems for both types of transports:
|
|
|
|
|
|
|
|
|
|
* Key management
|
|
|
|
|
* Trust management
|
|
|
|
|
* Identity management
|
|
|
|
|
|
|
|
|
|
pEp is supposed to provide Privacy by Default at least for message
|
|
|
|
|
content. It's providing meta data protection. And pEp is supposed to
|
|
|
|
|
provide technical data protection by implementing mix network
|
|
|
|
|
capabilities.
|
|
|
|
|
|
|
|
|
|
pEp is meant to be used in already existing messaging solutions. The use
|
|
|
|
|
cases of pEp are derived from the use cases from these solutions,
|
|
|
|
|
respectively.
|
|
|
|
|
|
|
|
|
|
Additionally, there are use cases for enterprise environments, where
|
|
|
|
|
e.g. some instance at the enterprise may need to look into the
|
|
|
|
|
messages. Reasons for this include compliance requirements or virus /
|
|
|
|
|
malware checking \[\[TODO: Decide whether those are covered herein\]\]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# Basic Use Cases and Functional Requirements
|
|
|
|
|
|
|
|
|
|
This section outlines the basic use cases and functional requirements.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Messages Exchange
|
|
|
|
|
|
|
|
|
|
* A peer sends an encrypted and signed message to another peer.
|
|
|
|
|
|
|
|
|
|
{::include ../shared/ascii-arts/use-case-send-msg.mkd}
|
|
|
|
|
* Offline Transport:
|
|
|
|
|
|
|
|
|
|
{::include ../shared/ascii-arts/use-case-offline-send-msg.mkd}
|
|
|
|
|
|
|
|
|
|
* Online Transport:
|
|
|
|
|
|
|
|
|
|
{::include ../shared/ascii-arts/use-case-online-send-receive-msg.mkd}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Note: Subcases of sending messages are outlined in
|
|
|
|
|
{{subcases-for-sending-messages}}.
|
|
|
|
|
|
|
|
|
|
* A peer receives an encrypted and signed message from another peer.
|
|
|
|
|
|
|
|
|
|
{::include ../shared/ascii-arts/use-case-receive-msg.mkd}
|
|
|
|
|
* Offline Transport:
|
|
|
|
|
|
|
|
|
|
{::include ../shared/ascii-arts/use-case-offline-receive-msg.mkd}
|
|
|
|
|
|
|
|
|
|
* Online Transport:
|
|
|
|
|
|
|
|
|
|
See above (Send and receive message combined)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Note: Subcases of sending messages are outlined in
|
|
|
|
|
{{subcases-for-receiving-messages}}.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Trust Management
|
|
|
|
|
|
|
|
|
|
* Trust of peer is established by using Trustwords
|
|
|
|
|
@ -116,54 +163,97 @@ This section outlines the basic use cases and functional requirements.
|
|
|
|
|
|
|
|
|
|
* Public Key is received the first time
|
|
|
|
|
|
|
|
|
|
* Trustwords have been compared sucessfully and confirmed by user
|
|
|
|
|
* Trustwords have been compared successfully and confirmed by user
|
|
|
|
|
(see above)
|
|
|
|
|
|
|
|
|
|
* Trust of a peer is revoked ((cf. {{key-management}}, key reset}}
|
|
|
|
|
|
|
|
|
|
* Trust is synchronized among different devices of the same user
|
|
|
|
|
|
|
|
|
|
{::include ../shared/ascii-arts/use-case-sync-trust.mkd}
|
|
|
|
|
* Offline Transport:
|
|
|
|
|
|
|
|
|
|
{::include ../shared/ascii-arts/use-case-offline-sync-trust.mkd}
|
|
|
|
|
|
|
|
|
|
* Online Transport:
|
|
|
|
|
|
|
|
|
|
{::include ../shared/ascii-arts/use-case-online-sync-trust.mkd}
|
|
|
|
|
|
|
|
|
|
Note: Sychronization management (such as establish or revoke trust)
|
|
|
|
|
Note: Synchronization management (such as establish or revoke trust)
|
|
|
|
|
among a user's own devices is described in
|
|
|
|
|
{{synchronization-managment}}
|
|
|
|
|
{{synchronization-management}}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Key Management
|
|
|
|
|
|
|
|
|
|
\[\[ TODO: Distinguish online and offline transport cases \]\]
|
|
|
|
|
|
|
|
|
|
* New Key pair is generated automatically (if none found) at startup
|
|
|
|
|
|
|
|
|
|
* Public Key is sent to peer by attaching it to messages
|
|
|
|
|
|
|
|
|
|
{::include ../shared/ascii-arts/use-case-send-key.mkd}
|
|
|
|
|
* Offline Transport:
|
|
|
|
|
|
|
|
|
|
{::include ../shared/ascii-arts/use-case-offline-send-key.mkd}
|
|
|
|
|
|
|
|
|
|
* Online Transport:
|
|
|
|
|
|
|
|
|
|
{::include ../shared/ascii-arts/use-case-online-send-receive-key.mkd}
|
|
|
|
|
|
|
|
|
|
* Public Key received by a peer is stored locally
|
|
|
|
|
|
|
|
|
|
{::include ../shared/ascii-arts/use-case-receive-key.mkd}
|
|
|
|
|
* Offline Transport:
|
|
|
|
|
|
|
|
|
|
{::include ../shared/ascii-arts/use-case-offline-receive-key.mkd}
|
|
|
|
|
|
|
|
|
|
* Online Transport:
|
|
|
|
|
|
|
|
|
|
See above (Send and receive public key combined)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* Key pair is declared invalid and other peers are informed (key reset)
|
|
|
|
|
|
|
|
|
|
{::include ../shared/ascii-arts/use-case-send-key-reset-key-msg.mkd}
|
|
|
|
|
* Offline Transport:
|
|
|
|
|
|
|
|
|
|
{::include ../shared/ascii-arts/use-case-offline-send-key-reset-key-msg.mkd}
|
|
|
|
|
|
|
|
|
|
* Online Transport:
|
|
|
|
|
|
|
|
|
|
{::include ../shared/ascii-arts/use-case-online-send-key-reset-key-msg.mkd}
|
|
|
|
|
|
|
|
|
|
* Public Key is marked invalid after receiving a key reset message
|
|
|
|
|
|
|
|
|
|
{::include ../shared/ascii-arts/use-case-receive-key-reset-msg.mkd}
|
|
|
|
|
|
|
|
|
|
* Offline Transport:
|
|
|
|
|
|
|
|
|
|
{::include ../shared/ascii-arts/use-case-offline-receive-key-reset-msg.mkd}
|
|
|
|
|
|
|
|
|
|
* Online Transport:
|
|
|
|
|
|
|
|
|
|
See above (Send and receive information combined)
|
|
|
|
|
|
|
|
|
|
* Private Key is synchronized among different devices of the same user
|
|
|
|
|
|
|
|
|
|
{::include ../shared/ascii-arts/use-case-sync-private-key.mkd}
|
|
|
|
|
* Offline Transport:
|
|
|
|
|
|
|
|
|
|
{::include ../shared/ascii-arts/use-case-offline-sync-private-key.mkd}
|
|
|
|
|
|
|
|
|
|
* Online Transport:
|
|
|
|
|
|
|
|
|
|
Note: Sycronization management (such as establish or revoke trust)
|
|
|
|
|
{::include ../shared/ascii-arts/use-case-online-sync-private-key.mkd}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Note: Synchronization management (such as establish or revoke trust)
|
|
|
|
|
among a user's own devices is described in
|
|
|
|
|
{{synchronization-managment}}
|
|
|
|
|
{{synchronization-management}}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Identity management
|
|
|
|
|
|
|
|
|
|
* All involved parties share the same identity system
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## User Interface
|
|
|
|
|
|
|
|
|
|
* Need for user interaction is kept to the minimum neecessary
|
|
|
|
|
* Need for user interaction is kept to the minimum necessary
|
|
|
|
|
|
|
|
|
|
* The privacy status of a peer is presented to the user by a color rating
|
|
|
|
|
|
|
|
|
|
@ -172,27 +262,39 @@ This section outlines the basic use cases and functional requirements.
|
|
|
|
|
* The color rating is defined by a traffic-light semantics
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Synchronization Managment
|
|
|
|
|
## Synchronization Management
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* A user of two or more devices establishes a trust relationship among
|
|
|
|
|
this devices so that e.g. private keys and trust can be synchronized
|
|
|
|
|
among the different devices
|
|
|
|
|
|
|
|
|
|
{::include ../shared/ascii-arts/use-case-sync-establishment.mkd}
|
|
|
|
|
* Offline Transport:
|
|
|
|
|
|
|
|
|
|
{::include ../shared/ascii-arts/use-case-offline-sync-establishment.mkd}
|
|
|
|
|
|
|
|
|
|
* Online Transport:
|
|
|
|
|
|
|
|
|
|
{::include ../shared/ascii-arts/use-case-online-sync-establishment.mkd}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* A user of two or more devices revokes trust of another device, any
|
|
|
|
|
further devices get informed and revoke trust to untrusted device.
|
|
|
|
|
\[\[ TODO: is this a use case? \]\]
|
|
|
|
|
|
|
|
|
|
{::include ../shared/ascii-arts/use-case-sync-revoke-client.mkd}
|
|
|
|
|
* Offline Transport:
|
|
|
|
|
|
|
|
|
|
{::include ../shared/ascii-arts/use-case-offline-sync-revoke-client.mkd}
|
|
|
|
|
|
|
|
|
|
* Online Transport:
|
|
|
|
|
|
|
|
|
|
{::include ../shared/ascii-arts/use-case-online-sync-revoke-client.mkd}
|
|
|
|
|
|
|
|
|
|
Note: Subcases for Trust Revoke are outlined in
|
|
|
|
|
{{subcases-for-trust-revoke}}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# Subcases and Preconditions
|
|
|
|
|
|
|
|
|
|
## Interaction States
|
|
|
|
|
@ -229,9 +331,9 @@ The following table shows the different interaction states possible:
|
|
|
|
|
| 6. | yes | yes | yes | yes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
In the simplicfied model, only interaction states 1, 2, 4 and 6 are
|
|
|
|
|
In the simplified model, only interaction states 1, 2, 4 and 6 are
|
|
|
|
|
depicted. States 3 and 5 may result from e.g. key mistrust or abnormal
|
|
|
|
|
user behaviour.
|
|
|
|
|
user behavior.
|
|
|
|
|
|
|
|
|
|
Note: As one peer may have several keys or if group conversations are
|
|
|
|
|
involved, thing will get more complex. For the time being, we focus on
|
|
|
|
|
@ -452,7 +554,8 @@ lorem ipsum
|
|
|
|
|
|
|
|
|
|
The authors would like to thank the following people who have provided
|
|
|
|
|
feedback or significant contributions to the development of this
|
|
|
|
|
document: Forename Surname, Forename2 Surname2, ...
|
|
|
|
|
document: Volker Birk
|
|
|
|
|
\[\[ TODO: Forename Surname, Forename2 Surname2, ...\]\]
|
|
|
|
|
|
|
|
|
|
lorem ipsum
|
|
|
|
|
|
|
|
|
|
|
