Browse Source

Intro + Threats/req.

master
iraklis 3 years ago
parent
commit
43974ec349
3 changed files with 16 additions and 11 deletions
  1. BIN
      misc/kramdown/.slides-92-edu-kramdown.pdf.icloud
  2. BIN
      misc/kramdown/slides-92-edu-kramdown.pdf
  3. +16
    -11
      pearg-analysis/draft-symeonidis-pearg-private-messaging-threat-analysis.mkd

BIN
misc/kramdown/.slides-92-edu-kramdown.pdf.icloud View File


BIN
misc/kramdown/slides-92-edu-kramdown.pdf View File


+ 16
- 11
pearg-analysis/draft-symeonidis-pearg-private-messaging-threat-analysis.mkd View File

@ -50,24 +50,23 @@ Modern email and instant messaging applications offer private communications, sh
# Introduction
Private messaging should ensure that, in an exchange of messages between (two) peers, no one but the sender and the receiver of the communication will be capable of reading the messages exchanged at any (current, future or past) time. That means, no one but the communicating peers should ever have access to the messages during transit and storage such as, telecom, internet providers, messaging servers or intermediary parties. As private messaging we are referring to instant messaging (IM) {{RFC 2779 Instant Messaging}}, such as WhatsApp and Signal, and to email applications (E), such as the centralized Protonmail and the fully decentralized pep {{birk-pep-04}}.
Private messaging should ensure that, in an exchange of messages between (two) peers, no one but the sender and the receiver of the communication will be capable of reading the messages exchanged at any (current, future or past) time. That means, no one but the communicating peers should ever have access to the messages during transit and storage such as telecom, internet providers, messaging servers or intermediary parties. As private messaging, we are referring to instant messaging (IM) {{RFC 2779 Instant Messaging}}, such as WhatsApp and Signal, and email applications (E), such as the centralized Protonmail and the fully decentralized pep {{birk-pep-04}}.
The aim of this current document (RFC draft) is to provide an open standard for private messaging requirements. It focuses on a unified evaluation framework. The framework catalogs the security and privacy threats and as well as the corresponding, to threats, requirements for private messaging. IM and E applications have common feature design characteristics and support a common set of information assets for transmission during communication between peers. For example, applications for both systems should support message exchange of text and files (e.g., attachments) in a private messaging manner.
The aim of this current document (RFC draft) is to provide an open standard for private messaging requirements. It aims to provide a unified evaluation framework. The framework catalogues security and privacy threats and the corresponding requirements. IM and E applications have common feature design characteristics and support a common set of information assets for transmission during communication between peers. For example, applications for both systems should support message exchange of text and files (e.g., attachments) in a private messaging manner.
It is essential to highlight that IM and EM have network design divergences such as responsiveness and synchronicity. For example, low-latency and synchronous were the common features for instant messaging and high-latency and asynchronous for emailing. However, nowadays IM applications tend to be asynchronous allowing delivery of messages when the communicating parties are not at the same time online. Of course, IM additionally can support voice/video calls, which is an additional feature/asset under which a treat assessemment and requirements can be evaluated (non english).
It is necessary to highlight that IM and EM have network design divergences such as responsiveness and synchronicity. For example, low-latency and synchronous were the common features for instant messaging and high-latency and asynchronous for emailing. However, nowadays, IM applications tend to be asynchronous, allowing delivery of messages when the communicating parties are not at the same time online.
Solutions available to implement private messaging in the two types of applications may call for different mitigation mechanisms and design choices. For instance, confidentiality can be preserved with various cryptographic primitives. As design choices it depends on the expected level of protection and the background of the user. For example, in specific where lives are at stake such as investigative journalists, whistle-blowers or dissidents from repressive countries the design choice for requirements and mitigation mechanism can be much more advanced (check) than organisations and "normal" users from the broad public. Yet, privacy and security on the Internet always are Human Rights and technological solutions should enable easily usable means to protect. But if somebody requires stronger protection, usability may be a second priority in favour of solutions offering a more profound protection (also hardware questions factor in more in these latter cases).
Solutions available to implement private messaging in the two types of applications may call for different mitigation mechanisms and design choices. For instance, confidentiality can be preserved in multiple wasy and with various cryptographic primitives. As design choices, it depends on the expected level of protection and the background of the user. For example, in specific where lives are at stake such as investigative journalists, whistle-blowers or dissidents from repressive countries the design choice for requirements and mitigation mechanism can be much more advanced than organizations and "normal" users from the broad public. Yet, privacy and security on the Internet always are Human Rights, and technological solutions should enable easily usable means to protect. But if somebody requires stronger protection, usability may be the second priority in favour of solutions offering more profound protection.
The objectives of this document is to:
The objectives of this document are to create an open standard for secure messaging requirements. The open standard for private messaging aims to serve as unified evaluation framework (i.e., adversarial model, threats and requirements). With this document, we catalogue the threats and requirements for implementing secure and private messaging systems. We focus on assets, threats/requirements and type of users utilizing private messaging systems. In this current version, we focus on two key design features of IM and EM, namely message delivering and message archiving, and so the work is on-going and the list of requirements we discuss here is not exhaustive. However, our work already shows an emerging and rich set of security and privacy challenges.
Create an open standard for secure messaging requirements. The open standard for private messaging aims to serve as unified evaluation framework (i.e., adversarial model, threats and requirements). With this document we catalogue the threats and requirements for implementing secure and private messaging systems. We focus on assets, threats/requirements and type of users utilizing private messaging systems. In this current version, we focus on two key design features of IM and EM, namely message delivering and message archiving, and so the work is on-going and the list of requirements we discuss here is not exhaustive. However, our work already shows an emerging and rich set of security and privacy challenges. Besides, several security and privacy mechanisms are available to address those challenges and herein we discuss them too (check again).
* Common pitfalls
* Future directions on requirements and technologies
# Of course, IM additionally can support voice/video calls, which is an additional feature/asset under which a treat assessment and requirements can be evaluated.
<!-
ß# Background
# Background
dev a system considering as a basis
selection of Threats
@ -91,12 +90,12 @@ anyboby who is building a system could refer to That
## Assets and functional Requirements
This section outlines a private messaging system. It describes the functionalities that needs to support and the information, as users' assets, that can be collected by the system. We follow the requirements extracted from real world systems and applications as well as from the academic literature for private emails and instant messaging {{Unger}} {{Ermoshina}} {{Clark}}.
This section outlines a private messaging system. It describes the functionalities that needs to support and the information, as users' assets, that can be collected by the system. We follow the requirements extracted from real world systems and applications as well as from the academic literature for emailing and instant messaging {{Unger}} {{Ermoshina}} {{Clark}}.
Assets:
* Content: text, files (e.g., attachments), voice/video
* Identities: sender/receiver identity, contact list
* Metadata: sender/receiver, timing, frequency, pack size
* Metadata: sender/receiver, timing, frequency, packet size
Functionalities:
* [E/IM] Messages: send and receive text + attachments
@ -144,6 +143,9 @@ monitor multiple channels of a system, while an internal local active
adversary can tamper with the messages of a targeted messaging
provider {{Diaz}}.
## Assumptions
In this current work, we assume that end points are secure such that the mobile devices of the users. Moreover, we assume that an adversary cannot break any of the underline cryptographic primitives.
## Security Threats and Requirements
@ -316,6 +318,9 @@ Relevant privacy considerations are outlined in
{{privacy-threats-and-requirements}}.
# Future key challenges
Reducing metadata leakage and standardization (i.e. prevent further fragmentation).
# IANA Considerations


Loading…
Cancel
Save