[MLS] Insider Replay Attack in MLS

["Kumar, Akshaya" <[e-mail]>]

Dear members of the MLS mailing list,

I am a PhD student at Georgia Tech studying cryptography. Over the past two years, my advisor Joseph Jaeger and I have been analyzing the compositions of symmetric encryption and digital signatures underlying the chat encryption algorithms in secure group messaging protocols (starting from our work on Keybase with Igors Stepanovs that appeared at Eurocrypt 2024). In current work we analyzed MLS and we believe that it is vulnerable to replay attacks by group insiders that result from the lack of authentication of the message generation. (The specification uses the term generation to denote a particular position in the sender ratchet). Below we give a brief overview of MLS chat encryption, describe the attack, and propose mitigations.

Chat encryption in MLS composes a digital signature scheme and an AEAD scheme in a Sign-then-Encrypt fashion. To encrypt a message from a sender to the group, the chat encryption algorithm first signs the group name, the epoch, the sender’s leaf index in the ratchet tree, the associated data, and the message using the sender’s signing key. It then encrypts the resulting signature and the message using an AEAD scheme where the corresponding encryption key and nonce are derived using the sender ratchet and the message generation. The data authenticated by the AEAD scheme contains the associated data, the group name, and the epoch. Notably, the signature does not authenticate the message generation, leading to the following insider replay attack.

In MLS group chats, every group member knows the sender ratchet secrets (and hence the encryption keys) for all members. A malicious member can decrypt a ciphertext to get a message and signature for some generation i and then re-encrypt them with the key and nonce for a different generation j. This ciphertext will be accepted as coming from the original sender because none of the information authenticated by the signature has changed, resulting in the message being replayed.

The MLS Architecture document (Section 8.3.1.1<https://messaginglayersecurity.rocks/mls-architecture/draft-ietf-mls-architecture.html#name-compromise-of-aead-keys>) considers a setting where the attacker knows the AEAD encryption keys but not the sender’s signing key and guarantees the following.

“Compromise of the AEAD keys allows the attacker to send an encrypted message using that key, but cannot send a message to a group which appears to be from any valid client since they cannot forge the signature.”

The attack can be easily mitigated if either the message generation or the encryption nonce (one of the two suffices since the nonce is derived from the generation) are additionally included as inputs to the digital signature scheme during the signing process. One way to achieve this would be to include the encryption nonce/generation as part of the associated data. The RFC<https://www.rfc-editor.org/rfc/rfc9420.html#section-6.3.1> currently does not specify what should be included in the associated data field, leaving this decision to the application. To ensure secure deployments, developers could be encouraged to always incorporate this information in the associated data, preventing the attack while remaining compliant with the current protocol.

We believe it would have been preferable for the protocol to always require the generation be an input to the signature, but this seems like a reasonable fix given that it does not.

We have a paper (currently under submission) covering this and other related work, which we will make public in the future.

Sincerely, Akshaya