Last active
January 2, 2016 01:09
-
-
Save Geal/8228049 to your computer and use it in GitHub Desktop.
rough threat model for group chat
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| # Threat model | |
| ## Attacker categories | |
| ### Security adversary | |
| Wants to read messages he is not supposed to. | |
| able to control communication channels and read/modify packets | |
| ### Consensus adversary | |
| wants participants to have different views of the conversation | |
| (ie, missing messages, messages with slight differences, | |
| ordering, etc) | |
| ### Privacy adversary | |
| -> the plausible deniability adversary | |
| Wants to be able to rpove that someone participated in a conversation | |
| ### Snitch | |
| not really a crypto adversary, but let's put him there for now | |
| snitches are a common real world adversary, and it is necessary to be able | |
| to eject them from a conversation | |
| ## Assets | |
| metadata about users: | |
| * who participates, since when, until when, from where (ip, etc), and their identity | |
| * who communicates with whom | |
| message content | |
| message relations (order, answers, etc) | |
| connection status (ability for every participant to communicate with each other) | |
| ## Threats | |
| * attacker reads messages on the wire | |
| * attacker modifies messages on the wire | |
| * attacker observes message size on the wire | |
| * attacker drops messages going to other participants | |
| * attacker drops messages coming from other participants | |
| * attacker delays messages to other participants | |
| * attacker delays messages from other participants | |
| * attacker sends messages to a conversation (not a participant) | |
| * attacker discovers one or more participants in a conversation | |
| * attacker obtains the encryption key for one message | |
| * attacker obtains the encryption key(s) for multiple messages | |
| * attacker prevents a participant from joining a conversation | |
| * attacker prevents a participant from following the conversation | |
| * attacker prevents multiple participants from following the conversation | |
| * attacker splits the conversation in two or more sets of participants | |
| * attacker obtains a shared MAC key of two participants | |
| * attacker obtains all the previous MAC keys of two participants at a certain point | |
| * attacker obtains all the previous MAC keys of all participants at a certain point | |
| * attacker sends a message on behalf of a user (appearing from its node) | |
| * attacker replays a message | |
| * attacker sends different messages to different participants | |
| * attacker abruptly disconnects participants | |
| * attacker asks for a rekeying | |
| * attacker adds multiple users | |
| * attacker adds a lot of bogus users | |
| * attacker sends a lot of bogus messages | |
| * attacker sends a lot of valid emssages (ex: replays? attacker is a participant?) | |
| * participant attacker asks for a rekeying | |
| * participant attacker floods the channel | |
| * attacker connects to the conversation, and tries to impersonate a previous participant |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I would add "non-participant attacker discovers the participants".
I don't think that association analysis of metadata is a threat that is external to the encryption part of the chat protocol. For example, SCIMP (silentcircle) includes a sequence number that is unencrypted, allowing fairly simple correlation of who is taking part in a chat regardless of what routing transport mechanism is used.