Matrix E2EE Threat Model

	A	B	C	D
1	Disclaimer: Work In Progress. This document is a work in progress and may contain incomplete, inaccurate, or outdated information. Content is subject to change without notice as the document is being actively updated.
2
3
4		Adversary / threat	Threat	Mitigation
5		Malicious server admins (aka compromised servers)
6			HS admin insert messages in my Rooms	Enable E2EE (unencrypted messages must be disallowed or strongly flagged in encrypted rooms)
7			Who add malicious devices into your account to receive new messages for your account	Private SSK required to sign new devices
8			Who invite malicious users into your rooms to spy on you	Look at the member list; in future, clients will sign membership events to control room membership
9			Who modify the /devices CS API to not report malicious devices on your account	Malicious devices would be unsigned so device signing and excluding unsigned devices (MSC4153) is an almost complete solution. The server can still withhold a malicious device on your account when you call /devices for yourself but return it to others. This would result in the attacker being unable to read messages you send but they would still be able to read messages you receive. This is mitigated with MSC4153; the remaining risk is in the homeserver consistently/persistently spoofing the user's entire cryptographic identity. To fully mitigate, you need to verify the user.
10			Who modify the human-visible metadata on the /devices CS API to camouflage malicious devices	In a MSC4153 world, this metadata is not very important and the issue becomes the same as the issue above.
11			Who add malicious backups onto your account in order to intercept your keys	Backup signed by master key, devices only write to it if backup sig verified.
12			[Verification] Who add malicious SAS verification event	Clients won't be able to generate same shared secret (DH) -> untrusted
13			[Verification] Malicious Automatic QR code reciprocate	Two-way verification: users prompted to ensure success on partner's side
14			who modify key/query to replace my public keys	other client won't trust my devices then (invalid signature chain). On login my new session will detect it after verification/passphrase and ask to replace keys
15			Malicious default integration server (integration widget can modify room members, powerlevels,..)	Guarded by authorisation / accept terms?
16			Malicious widget (IP leak)	Guarded by authorisation to open
17			Publishing malicious OTKs on behalf of users to intercept Olm sessions	Guarded by OTKs being signed
18		MITM HTTPS attacks		Message content protected by e2e
19		Data from interception by a Global Passive Adversary (GPA)		HTTPS, message content encryption
20		DNS hijack / reuse attacks		HTTPS X.509 for HS DNS hijack, user key verification prevents DNS resuse being same user (for e2e rooms only)
21		Replay attacks		Only single message at each session index permitted
22		Unknown keyshare attacks		OTKs signed? User is prompted
23		Attacks on forward secrecy (i.e. being able to decrypt old messages based on a snapshot of current encryption state)		Ratcheting, although note Element stores all historic keys (but could choose not to store older keys, and instead 'restore' them in on demand)
24		Interception/interference from cloned devices (e.g. restored from backups)		No mitigation? dkasak: This is very similar to "on device attacks" in some sense, which we deliberately do not protect against as per below. We would still like to be able to detect cloned devices better.
25		Attacks on deniability. (e.g. cryptographically speaking, whilst the sender should be authenticated time of sending, there should not be proof in retrospect of their identity. For instance, it could have been a malicious server admin.).		(Do we sacrifice this by signing our OTKs?)
26		Timing side-channel attacks.		Good mitigation if using vodozemac
27		Passive Attacks on out-of-band verification (e.g. shouldersurfing a QR code or bugging an OOB SAS code)		Two-way verification: users prompted to ensure success on partner's side
28		I left an opened session on a computer		Can't take control of account (re-auth needed to change pwd, add mail, upload new signing keys) Can logout session from another session (with re-auth)
29
30	Stuff we don’t try to protect against:
31		On-device attacks
32		Malicious/buggy clients
33		Metadata interception by a malicious server admin
34		Metadata interception by a global passive adversary (GPA)
35		Malicious servers withholding messages from being sent to clients or servers
36		Transcript consistency attacks in general
37		Attacks on post compromise secrecy within a given megolm session (i.e. being able to decrypt new messages based on a snapshot of current encryption state)
38		Compromise of megolm keys (via interception on client, or intercepting recovery key/passphrase for an online/offline key backup)
39		Evil maid or rubber hose attacks on megolm key backup keys/passphrases
40		Brute force attacks on megolm key backups (offline & online)
41		Active Attacks on out-of-band verification (e.g. using a speech synthesizer to fake text auth comparison, or an attacker tricking you to showing a screenshot of a compromised QR code on your phone to fake a QR verification)
42		File size exposure of encrypted attachments to a malicious media repository owner or server admin
43
44	Glossary:		Legend:
45	GPA	Global Passive Adversary	No mitigation
46	OTK	One-Time Key	Good mitigation for those who verify
47	SAS	Short Authentication Strings	Good mitigation for all
48	DH	Diffie-Hellman
49	MITM	Man-in-the-middle
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100