|
|
@ -117,66 +117,6 @@ latter cases). |
|
|
|
* Misleading products on the wild (EFF secure messaging scorecard) |
|
|
|
|
|
|
|
|
|
|
|
## Known Implementations |
|
|
|
|
|
|
|
### Pretty Easy Privacy (pEp) {#pEp} |
|
|
|
|
|
|
|
To achieve privacy of exchanged messages in an opportunistic way |
|
|
|
{{RFC7435}}, the following model (simplified) is proposed by pEp |
|
|
|
(pretty Easy Privacy) {{I-D.birk-pep}}: |
|
|
|
|
|
|
|
{::include ../shared/ascii-arts/basic-msg-flow.mkd} |
|
|
|
|
|
|
|
<vspace blankLines="10" /> |
|
|
|
|
|
|
|
|
|
|
|
<!-- 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 intended to solve three problems <!-- for both types of |
|
|
|
transports -->: |
|
|
|
|
|
|
|
* Key management |
|
|
|
|
|
|
|
* Trust management |
|
|
|
|
|
|
|
* Identity management |
|
|
|
|
|
|
|
pEp is intended to be used in pre-existing messaging solutions and |
|
|
|
provide Privacy by Default, at a minimum, for message content. In |
|
|
|
addition, pEp provides technical data protection including metadata |
|
|
|
protection. |
|
|
|
|
|
|
|
An additional set of use cases applies to enterprise environments |
|
|
|
only. In some instances, the enterprise may require access to message |
|
|
|
content. Reasons for this may include the need to conform to |
|
|
|
compliance requirements or virus/malware defense. |
|
|
|
|
|
|
|
|
|
|
|
### Autocrypt |
|
|
|
|
|
|
|
Another known approach in this area is Autocrypt. Compared to pEp |
|
|
|
(cf. {{pEp}}) - there are certain differences, for example, regarding |
|
|
|
the prioritization of support for legacy PGP {{RFC4880}} |
|
|
|
implementations. |
|
|
|
|
|
|
|
|
|
|
|
More information on Autocrypt can be found on: |
|
|
|
https://autocrypt.org/background.html |
|
|
|
|
|
|
|
|
|
|
|
\[\[ TODO: Input from autocrypt group \]\] |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Focus Areas (Design Challenges): |
|
|
|
|
|
|
@ -213,9 +153,9 @@ instant messaging {{Unger}} {{Ermoshina}} {{Clark}}. |
|
|
|
* Multi-device support: synchronization across multiple devices |
|
|
|
* Group messaging: communication of more than 2 users |
|
|
|
|
|
|
|
\[\[ TODO: Add more text on Group Messaging requirements. \]\] |
|
|
|
|
|
|
|
# Threat Analyses |
|
|
|
|
|
|
|
# Threat Analyses and requirements |
|
|
|
|
|
|
|
This section describes a set of possible threats. Note that not all |
|
|
|
threats can be addressed, due to conflicting requirements. |
|
|
@ -405,310 +345,6 @@ contradict that a specific user sent a particular message. Deniability |
|
|
|
can be guaranteed through the use of cryptographic protocols such as |
|
|
|
off-the-record messaging. |
|
|
|
|
|
|
|
<!-- =================================================================== --> |
|
|
|
|
|
|
|
<vspace blankLines="4" /> |
|
|
|
\[\[ TODO: Describe relation of the above introduced Problem Areas to |
|
|
|
scope of MEDUP \]\] |
|
|
|
|
|
|
|
|
|
|
|
<!-- |
|
|
|
# Scope of MEDUP |
|
|
|
|
|
|
|
As some of the above introduced Problem Areas {{problem-areas}} |
|
|
|
conflict with each other or other ares of MEDUP, those need to |
|
|
|
prioritized. |
|
|
|
|
|
|
|
## Problem Areas addressed by MEDUP |
|
|
|
|
|
|
|
In MEDUP the following of the above introduced Problem Areas |
|
|
|
{{problem-areas}} will be addressed primarily: |
|
|
|
|
|
|
|
\[\[TODO: Move some of this this to next subsection \]\] |
|
|
|
|
|
|
|
|
|
|
|
* Spoofing and Entity Authentication |
|
|
|
(cf. {{spoofing-and-entity-authentication}}) |
|
|
|
|
|
|
|
* Information Disclosure and Confidentiality |
|
|
|
(cf. {{information-disclosure-and-confidentiality}}) |
|
|
|
|
|
|
|
* Tampering With Data and Data Authentication |
|
|
|
(cf. {{tampering-with-data-and-data-authentication}}) |
|
|
|
|
|
|
|
* Repudiation and Accountability (Non-Repudiation) |
|
|
|
(cf. {{repudiation-and-accountability-non-repudiation}}) |
|
|
|
|
|
|
|
* Identifiability -\- Anonymity (cf. {{identifiability-anonymity}}) |
|
|
|
|
|
|
|
* Linkability -\- Unlinkability (cf. {{linkability-unlinkability}}) |
|
|
|
|
|
|
|
* Detectability and Observatility -\- Unditectability |
|
|
|
(cf. {{detectability-and-observatility-unditectability}}) |
|
|
|
|
|
|
|
* Information Disclosure -\- Confidentiality |
|
|
|
(cf. {{information-disclosure-confidentiality}}) |
|
|
|
|
|
|
|
* Non-Repudiation and Deniability |
|
|
|
(cf. {{non-repudiation-and-deniability}}) |
|
|
|
|
|
|
|
## Problem Areas addressed by MEDUP |
|
|
|
|
|
|
|
The following of the above introduced Problem Areas {{problem-areas}} |
|
|
|
MAY be addressed in MEDUP only to the extent as they are not in |
|
|
|
conflict with the Problem Areas addressed by MEDUP. |
|
|
|
|
|
|
|
* ... |
|
|
|
|
|
|
|
|
|
|
|
\[\[TODO: Move some of this this from previous subsection \]\] |
|
|
|
|
|
|
|
--> |
|
|
|
|
|
|
|
<!-- =================================================================== --> |
|
|
|
|
|
|
|
|
|
|
|
# Specific Security and Privacy Requirements |
|
|
|
|
|
|
|
\[\[ This section is still in early draft state, to be substantially |
|
|
|
improved in future revisions. Among other things, there needs to be |
|
|
|
clearer distinction between MEDUP requirements, and those of a |
|
|
|
specific implementation. |
|
|
|
\]\] |
|
|
|
|
|
|
|
|
|
|
|
## Messages Exchange |
|
|
|
|
|
|
|
### Send Message |
|
|
|
|
|
|
|
* Send encrypted and signed message to another peer |
|
|
|
|
|
|
|
* Send unencrypted and unsigned message to another peer |
|
|
|
|
|
|
|
Note: Subcases of sending messages are outlined in |
|
|
|
{{subcases-for-sending-messages}}. |
|
|
|
|
|
|
|
### Receive Message |
|
|
|
|
|
|
|
* Receive encrypted and signed message from another peer |
|
|
|
|
|
|
|
* Receive encrypted, but unsigned message from another peer |
|
|
|
|
|
|
|
* Receive signed, but unencrypted message from another peer |
|
|
|
|
|
|
|
* Receive unencrypted and unsigned message from another peer |
|
|
|
|
|
|
|
Note: Subcases of receiving messages are outlined in |
|
|
|
{{subcases-for-receiving-messages}}. |
|
|
|
|
|
|
|
|
|
|
|
## Trust Management |
|
|
|
|
|
|
|
* Trust rating of a peer is updated (locally) when: |
|
|
|
|
|
|
|
* Public Key is received the first time |
|
|
|
|
|
|
|
* Trustwords have been compared successfully and confirmed by user |
|
|
|
(see above) |
|
|
|
|
|
|
|
* Trust of a peer is revoked (cf. {{key-management}}, Key Reset) |
|
|
|
|
|
|
|
* Trust of a public key is synchronized among different devices of the |
|
|
|
same user |
|
|
|
|
|
|
|
Note: Synchronization management (such as the establishment or |
|
|
|
revocation of trust) among a user's own devices is described in |
|
|
|
{{synchronization-management}} |
|
|
|
|
|
|
|
|
|
|
|
## Key Management |
|
|
|
|
|
|
|
* New Key pair is automatically generated at startup if none are found. |
|
|
|
|
|
|
|
* Public Key is sent to peer via message attachment |
|
|
|
|
|
|
|
* Once received, Public Key is stored locally |
|
|
|
|
|
|
|
* Key pair is declared invalid and other peers are informed (Key Reset) |
|
|
|
|
|
|
|
* Public Key is marked invalid after receiving a key reset message |
|
|
|
|
|
|
|
* Public Keys of peers are synchronized among a user's devices |
|
|
|
|
|
|
|
* Private Keys are synchronized among a user's devices |
|
|
|
|
|
|
|
Note: Synchronization management (such as establish or revoke trust) |
|
|
|
among a user's own devices is described in |
|
|
|
{{synchronization-management}} |
|
|
|
|
|
|
|
|
|
|
|
## Synchronization Management |
|
|
|
|
|
|
|
A device group is comprised of devices belonging to one user, which |
|
|
|
share the same key pairs in order to synchronize data among them. In |
|
|
|
a device group, devices of the same user mutually grant |
|
|
|
authentication. |
|
|
|
|
|
|
|
* Form a device group of two (yet ungrouped) devices of the same user |
|
|
|
|
|
|
|
<!-- |
|
|
|
Note: Preconditions for forming a device group are outlined in |
|
|
|
{{preconditions-for-forming-a-device-group}}. |
|
|
|
--> |
|
|
|
|
|
|
|
* Add another device of the same user to existing device group |
|
|
|
|
|
|
|
* Leave device group |
|
|
|
|
|
|
|
* Remove other device from device group |
|
|
|
|
|
|
|
|
|
|
|
## Identity Management |
|
|
|
|
|
|
|
* All involved parties share the same identity system |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## User Interface |
|
|
|
|
|
|
|
\[\[ TODO \]\] |
|
|
|
|
|
|
|
<!-- |
|
|
|
|
|
|
|
* Need for user interaction is kept to the minimum necessary |
|
|
|
|
|
|
|
* The privacy status of a peer is presented to the user in a easily |
|
|
|
understandable way, e.g. by a color rating |
|
|
|
|
|
|
|
* The privacy status of a message is presented to the user in a easily |
|
|
|
understandable way, e.g. by a color rating |
|
|
|
|
|
|
|
* The color rating is defined by a traffic-light semantics |
|
|
|
|
|
|
|
\[\[ TODO: rewrite "in a easily understandable way} \]\] |
|
|
|
|
|
|
|
--> |
|
|
|
|
|
|
|
# Subcases |
|
|
|
|
|
|
|
<!-- Do we need this section at all? --> |
|
|
|
|
|
|
|
## Interaction States |
|
|
|
|
|
|
|
The basic model consists of different interaction states: |
|
|
|
|
|
|
|
<!-- nk] you might consider changing the numbers, to a three-fold |
|
|
|
system (for 3 different cases). And repeat the same numbering with |
|
|
|
differentiating them in the subcases in the table below. Also it would |
|
|
|
be good to have some explanation when or why these cases occur, maybe |
|
|
|
link them with a timeline of starting and establishing a conversation |
|
|
|
as well as an explicit reference to the TOFU concept. --> |
|
|
|
|
|
|
|
1. Both peers have no public key of each other, no trust possible |
|
|
|
|
|
|
|
2. Only one peer has the public key of the other peer, but no trust |
|
|
|
|
|
|
|
3. Only one peer has the public key of the other peer and trusts |
|
|
|
that public key |
|
|
|
|
|
|
|
4. Both peers have the public key of each other, but no trust |
|
|
|
|
|
|
|
5. Both peers have exchanged public keys, but only one peer trusts the |
|
|
|
other peer's public key |
|
|
|
|
|
|
|
6. Both peers have exchanged public keys, and both peers trust the |
|
|
|
other's public key |
|
|
|
|
|
|
|
|
|
|
|
The following table shows the different interaction states possible: |
|
|
|
|
|
|
|
| state | Peer's Public Key available | My Public Key available to Peer | Peer Trusted | Peer trusts me | |
|
|
|
| ------|:---------------------------:|:-------------------------------:|:------------:|:--------------:| |
|
|
|
| 1. | no | no | N/A | N/A | |
|
|
|
| 2a. | no | yes | N/A | no | |
|
|
|
| 2b. | yes | no | no | N/A | |
|
|
|
| 3a. | no | yes | N/A | yes | |
|
|
|
| 3b. | yes | no | yes | N/A | |
|
|
|
| 4. | yes | yes | no | no | |
|
|
|
| 5a. | yes | yes | no | yes | |
|
|
|
| 5b. | yes | yes | yes | no | |
|
|
|
| 6. | yes | yes | yes | yes | |
|
|
|
|
|
|
|
|
|
|
|
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 behavior. Interaction states 1, 2 and 4 are part of |
|
|
|
TOFU. For a better understanding, you may consult the figure in |
|
|
|
{{pEp}} above. |
|
|
|
|
|
|
|
|
|
|
|
Note: In situations where one peer has multiple key pairs, or group |
|
|
|
conversations are occurring, interaction states become increasingly |
|
|
|
complex. For now, we will focus on a single bilateral interaction |
|
|
|
between two peers, each possessing a single key pair. |
|
|
|
|
|
|
|
\[\[ Note: Future versions of this document will address more complex |
|
|
|
cases \]\] |
|
|
|
|
|
|
|
|
|
|
|
## Subcases for Sending Messages |
|
|
|
|
|
|
|
* If peer's Public Key not available (Interaction States 1, 2a, and |
|
|
|
3a) |
|
|
|
|
|
|
|
* Send message Unencrypted (and unsigned) |
|
|
|
|
|
|
|
* If peer's Public Key available (Interaction States 2b, 3b, 4, 5a, |
|
|
|
5b, 6) |
|
|
|
|
|
|
|
* Send message Encrypted and Signed |
|
|
|
|
|
|
|
|
|
|
|
## Subcases for Receiving Messages |
|
|
|
|
|
|
|
* If peer's Public Key not available (Interaction States 1, 2a, and |
|
|
|
3a) |
|
|
|
|
|
|
|
* If message is signed |
|
|
|
|
|
|
|
* ignore signature |
|
|
|
|
|
|
|
* If message is encrypted |
|
|
|
|
|
|
|
* decrypt with caution |
|
|
|
|
|
|
|
* If message unencrypted |
|
|
|
|
|
|
|
* No further processing regarding encryption |
|
|
|
|
|
|
|
* If peer's Public Key available or can be retrieved from received |
|
|
|
message (Interaction States 2b, 3b, 4, 5a, 5b, 6) |
|
|
|
|
|
|
|
* If message is signed |
|
|
|
|
|
|
|
* verify signature |
|
|
|
|
|
|
|
* If message is encrypted |
|
|
|
|
|
|
|
* Decrypt |
|
|
|
|
|
|
|
* If message unencrypted |
|
|
|
|
|
|
|
* No further processing regarding encryption |
|
|
|
|
|
|
|
* If message unsigned |
|
|
|
|
|
|
|
* If message is encrypted |
|
|
|
|
|
|
|
* exception |
|
|
|
|
|
|
|
* If message unencrypted |
|
|
|
|
|
|
|
* No further processing regarding encryption |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<!-- =================================================================== --> |
|
|
|
|
|
|
|
|
|
|
|