I think this is the most impactful set of cryptographic findings ever presented against any secure messaging system. I don't think the authors agree with me, but I'll say it anyways: this is a landmark paper.
Here are the findings:
1. The Matrix protocol, as designed at the time, gave servers control over both group membership and over device ownership. Because all Matrix messages in practice are group messages, this means that servers control all the keys, and can decrypt arbitrary messages. They can do that by surreptitiously injecting "users" into groups, whereupon the members of the group will send that "user" their group key, or by surreptitiously adding devices to user accounts.
2. The out-of-band key verification primarily used by Matrix (there are several, this is I think the primary one), SAS, was cryptographically broken. There are a variety of long-term keys managed for each Matrix account; in the SAS subprotocol, 2 of those keys are used without domain separation (that is, no identifier is mixed into the protocol to mathematically establish "this key should only be valid if it was generated in the context of this use"). As a result, servers can spoof SAS completion for users by cleverly arranging identifiers for those users.
3. Servers can spoof user messages, simply by slapping another user's identity on "forwarded room key" messages. This produces a warning, and is a building-block attack.
4. Matrix uses two different cryptographic messaging protocols, Olm and Megolm. Olm is a point-to-point cryptographic ratchet (think classic Signal), and Megolm is the group protocol. Matrix uses Olm for housekeeping tasks and Megolm for messaging. Both protocols keep their own cryptographic state. You can confuse a Matrix target by unexpectedly mixing Olm and Megolm messages, in tandem with the previous building-block attack, to spoof user identities without any warnings (you do this by spoofing open a Megolm "channel", which is like a messaging leg of a Matrix group).
5. Matrix has an encrypted backup subprotocol so that the server can escrow keys between devices (that is, Matrix provides secure encrypted storage of message state for users, ostensibly arranged so the server can't read any of it). The previous reliable spoofing attack can be used by the server to break it, and recover any user's encrypted state: you spoof a user to themselves and trick them into setting a backup key that you control.
Some obvious takeaways here:
* In a group secure messaging protocol, group membership is key management. If group membership is insecure, the system is insecure. Matrix isn't the first secure messenger to blow up over group membership.
* All modern secure messengers are complex. If you look at Signal's design, you'll see cryptographic construction on top of cryptographic construction. But a sound protocol is restrained. The pieces all fit together organically. Matrix, on the other hand, sprawls. There is a tremendous amount of stuff going on, and it's difficult to reason about.
* The Matrix team is responding to these vulnerabilities by altering the protocol. That's good. But the initial response given to the researchers regarding group membership was that they were going to accept the risk(!) of server-controlled group messaging, and concentrate on ensuring warnings were reliably given to users. Group membership is key management. By the time you're reading a warning, an attacker is decrypting messages. To shoplift the words of a great sage, the god-damned plane has crashed into the mountain.
For the sake of accuracy, it’s worth pointing out that points 2 through 5 were implementation bugs resolved in https://matrix.org/blog/2022/09/28/upgrade-now-to-address-en.... They are not current attacks, despite the present tense used to describe them in the parent post.
Also note that in the review of the ecosystem the Matrix developers, i.e you :), also discovered further clients vulnerable to variants of attack #3 and assigned CVE-2022-39252, CVE-2022-39254 and CVE-2022-39264.
Here are the findings:
1. The Matrix protocol, as designed at the time, gave servers control over both group membership and over device ownership. Because all Matrix messages in practice are group messages, this means that servers control all the keys, and can decrypt arbitrary messages. They can do that by surreptitiously injecting "users" into groups, whereupon the members of the group will send that "user" their group key, or by surreptitiously adding devices to user accounts.
2. The out-of-band key verification primarily used by Matrix (there are several, this is I think the primary one), SAS, was cryptographically broken. There are a variety of long-term keys managed for each Matrix account; in the SAS subprotocol, 2 of those keys are used without domain separation (that is, no identifier is mixed into the protocol to mathematically establish "this key should only be valid if it was generated in the context of this use"). As a result, servers can spoof SAS completion for users by cleverly arranging identifiers for those users.
3. Servers can spoof user messages, simply by slapping another user's identity on "forwarded room key" messages. This produces a warning, and is a building-block attack.
4. Matrix uses two different cryptographic messaging protocols, Olm and Megolm. Olm is a point-to-point cryptographic ratchet (think classic Signal), and Megolm is the group protocol. Matrix uses Olm for housekeeping tasks and Megolm for messaging. Both protocols keep their own cryptographic state. You can confuse a Matrix target by unexpectedly mixing Olm and Megolm messages, in tandem with the previous building-block attack, to spoof user identities without any warnings (you do this by spoofing open a Megolm "channel", which is like a messaging leg of a Matrix group).
5. Matrix has an encrypted backup subprotocol so that the server can escrow keys between devices (that is, Matrix provides secure encrypted storage of message state for users, ostensibly arranged so the server can't read any of it). The previous reliable spoofing attack can be used by the server to break it, and recover any user's encrypted state: you spoof a user to themselves and trick them into setting a backup key that you control.
Some obvious takeaways here:
* In a group secure messaging protocol, group membership is key management. If group membership is insecure, the system is insecure. Matrix isn't the first secure messenger to blow up over group membership.
* All modern secure messengers are complex. If you look at Signal's design, you'll see cryptographic construction on top of cryptographic construction. But a sound protocol is restrained. The pieces all fit together organically. Matrix, on the other hand, sprawls. There is a tremendous amount of stuff going on, and it's difficult to reason about.
* The Matrix team is responding to these vulnerabilities by altering the protocol. That's good. But the initial response given to the researchers regarding group membership was that they were going to accept the risk(!) of server-controlled group messaging, and concentrate on ensuring warnings were reliably given to users. Group membership is key management. By the time you're reading a warning, an attacker is decrypting messages. To shoplift the words of a great sage, the god-damned plane has crashed into the mountain.