Beyond Secure Messaging - talk 4 of 4 (RWC 2026)

Added: 2026-05-17

[00:00:00]cooperation on that. I really appreciate it. So, go ahead guys.

[00:00:09]So, welcome everybody. I'm Notozo and today Kian and I are going to talk about how signal lost integrity in conversations a joint work with Peter Schwab and Kenny Patterson.

[00:00:24]First of all, what's signal? Well, the answer to the qu this question mainly depends who we are asking the question to because if we ask to a normal user, Signal is just the messaging app. On the other end, if we ask to someone that works in security or cryptography, Signal is the gold standard for secure messaging and is also a collection of cryptographic protocols.

[00:00:47]And just to give you an overview, these are some of uh the main cryptographic protocols of Signal that have been analyzed by many security analysis that used pen and paper proofs but also symbolic and computational modeling tools and um the problem is that all these analysis have been done analyzing the single protocols in isolation. This means that all the interactions between these subcomponents have not been analyzed and uh therefore we missed the forest for the trees because we didn't analyze the system as a whole and it is exactly here that our work took place.

[00:01:29]Just to give you some background on uh where we worked on since 2024, Signal introduced usernames as a means of enhancing uh in order to enhance privacy in order to contact other users. So while in the past to contact another user on in on a signal you needed to know basically their phone number and phone numbers were publicly visible since 2024.

[00:01:54]You can contact another user by knowing their username. And in cryptographic terms, this implied that the identity of a user was also split uh in two identifiers. Each user has this ACI identifier, also known as account identifier that is associated with a keeper and is a stable identifier because the corresponding public key is sashed within the safety number. And then a user has also this other identifier that is named the PNI or phone number identifier that is also associated with the keep pair and with the phone number of a user according to how a user wants to establish uh a session with another user. Uh the a different type of session is generated because when the initiator wants to establish a session by knowing the username of the other user an ACI session is established. Instead, if the initiator wants to establish a a session by knowing the phone number of another user, an SEI PNI session is generated and then it is upgraded by the receiver to an SEIC session that is considered the primary session, the stable one because it can be checked through safety numbers. A natural question from the audience could be what about the PNI of the initiator? Cannot the initiator establish a session with a PNI. The answer is no because uh in signal users this is not the natural behavior.

[00:03:20]Clients are not supposed to establish sessions that have an PNI as a source address.

[00:03:27]So let's go uh let's zoom in on this concept of upgrading to ACI.

[00:03:33]Uh whenever Ellis our initiator wants to contact Bob, establish a session with Bob by knowing his phone number, she knows Bob's PNI and the corresponding PNI public key. So the two establish his session and uh since Bob saw that Ellis contacted him to his phone number identifier, he understands that Ellis is missing information on his ACI.

[00:03:57]Therefore, what it does is that he signs his ACI public key with the is PNI secret key whose corresponding public key is known by Ellis and then uh he sends this uh signature to Ellis. The two establish this ACI session and upon successful verification of this signature, Ellis is able to merge all the cryptographic identities of Bob. So both ACI and PNI uh into the logical identity of Bob as a user. Therefore, whenever Bob sends a message to Ellis, regardless of the identifier that he's use using, this message will show up in the same conversation that Ellis has with Bob. And as I mentioned before, we worked on uh basically the level of interactions between protocols because we call this flow the PNIC protocol and we call like this because it was not present in signal documentation.

[00:04:51]However, this protocol involves other protocols such as the X3DH to the key establishment and then also the double ratchet protocol for whenever the two parties want to exchange messages and then the SEM protocol that is the session management protocol and is exactly this PNI to CI protocol that this I described here that we exploited with our attack. So our attack introduces a uh malicious server meal that knows Bob's phone number identifier that here I call PNI tilda because it's exactly the same as PNI. What changes is that the associated key pair was maliciously generated by Mallalerie. So Mallerie wants to establish a session with Ellis uh on behalf of Bob. So what she does is that she sends a pricky message to Ellis and this pricky message contains the PNI of Bob that is exactly the same as PNI B tilda. Then the cipher text of a message that Mallerie wants to send uh to Ellis that was encrypted with the key resulting from the key establishment of the new generated session SEIS PNIB tild and then the maliciously generated public key uh PNI public key tilder. So um what happens from uh Ellie's side on her graphical interface on her chat with Bob is that she sees that this notification your safety number with Bob has changed and this happens because previously with the PNI toi protocol she managed to merge the cryptographic identities of Bob into the logical identity. This means that Ellis already knew Bob's PNI public key. And here she's noticing that there is a different public key involved. That is the one that was maliciously generated by Mallerie. Therefore, she sees this notification on her chat with Bob. And what she can do is of course to go to Bob and then autoband double check the two safety numbers on both sides and see if the two numbers coincide. And they do. So on both sides, it looks like everything is going well. But now she's establishing this new session with Mallerie and is able to decrypt the message that oops it looks like you have been fired Ellis as if it was coming from Bob. And at this point in time Ellis has three active sessions with with two with Bob and one with Mallerie.

[00:07:16]And of course Bob is not able to see the injected message.

[00:07:21]More information about this attack is that it can be repeated several times by injecting new messages with the only difference that after the first injected message uh Ellis will not see any more safety number change and notification and this is because she's using the same established session with Mallerie and the attack can also be done birectionally with more requirements from Bobside and uh to know more about it stay tuned for when the paper will be out.

[00:07:51]This vulnerability affected both the desktop and Android platforms up to the these uh versions and uh we responsibly disclosed the vulnerability to signal in uh September 2025 and we have to praise the fact that signal was really fast in fixing patching the code. We have to say that uh um they fixed it for a desktop the day itself and for Android two days after and the patch consisted in not accepting messages that are coming from a PNI.

[00:08:25]Now I've been talking about Ellis Bob Mallerie as abstract identities but let's give them some human aspect. What if Bob is an influential political figure and Ellis is as well? Or what if Ellis is a journalist that lives in a high-risk environment and she receives a message coming from a trusted party to meet maybe in some place.

[00:08:53]She could be caught in a trap and her life could be put in danger. That's why an attack and injection like attack like this could have devastating impact also on human lives.

[00:09:05]Thank you very much for the attention and to break more stuff. These are our contacts.

[00:09:10]>> Before you get to the questions, I have just one more thing. So we said in the abstract that we present an attack and no me presented to you an attack. Well, today is your lucky day. You have two attacks. That's right. That's true attacks for the price of one. But wait, there's more.

[00:09:29]The previous attack said that honest users receive a notifications about their safety numbers. However, this new attack uh ensures that users don't receive any notification at all. This attack is undetectable. Now, to understand why this works, we have to combine two issues. The first issue is in lip signal and regards sender authentication in sealed sender. The second issue is in the Android version of the app and regards how messages which are coming from the server are validated. The combination of these two issues allows undetectable message injection from a malicious server.

[00:10:03]Signal seal sender is a signals protocol to ensure that the identity of the sender is hidden from from the server itself. And the way it works is that we have Alice who wants to wrap a message M. And you can think of this message M as being a double ratchet encrypted message or a sender keys encrypted message for group messages.

[00:10:22]What Alice does, she sends a cipher text composed of two parts. The first part is simply a public key encryption directed towards Bob of her identity. By which I mean her public key and her address, her ACI address which reveals her identity only to Bob.

[00:10:40]um to prevent malicious users from claiming to be Alice, there is a certificate which is created by the signal server which attests to this association between a public key and an address. Now the second part of the cipher text is simply an authenticated public key encryption using the public key contained in the first part of the message and wrapping the message M. Now this ensures that it was sent by Alice and Bob now has the message M and the server does not know who the sender was.

[00:11:14]Now all of this is great. However, the certificate does not provide much if the server is malicious. Now imagine the the following situation.

[00:11:23]The server puts a a key PKM of which they know the secret key and issues a certificate third prime and then uses PKM inside that um uses PKM for the second part of the message. Now Bob will accept this message M because the certificate is valid and everything decrypts correctly and in fact Bob could check whether PKM is the key that he knows for Alice but in lip signal this is not present.

[00:11:52]So this means that the server can send seal sender messages on behalf of anybody. Now when I tell you that the signal server can send seal sender messages on behalf of any user, you might tell to me the thing that I was saying before that there's another layer of authentication provided by the double ratchet and sender keys. Right.

[00:12:12]Right. Well to understand better what happens we have to look at the structure of messages. And what I mean by this is that for example we have a message here which is composed of an envelope in plain text. Inside there is the type of the message. In this case it's a whisper message which means it's a double ratchet encrypted message and the source. And inside there is the double ratchet message itself which is encrypted. And inside there is a structure which is which contains the text message. When you receive this sort of message you will see it's from Alice.

[00:12:43]It's a text message. I'm going to display this in my chat with Alice. More or less. This is what happens also for groups just that it happens to be in a group set in a in a group chat. But there is a third less known type of message which is a plain text message.

[00:12:58]Now a plain text message is not authenticated. Therefore, because there is no authentication, plain text messages which contain text messages cannot be accepted. And usually they would only carry decryption error messages because of course if you do not have a cryptographic correct cryptographic state, the other party cannot decrypt and therefore they will send you a message containing a decryption error. Now the way this is the validation is done in Android is that the type in the envelope is checked and then if the type is plain text content it checks inside and if inside there is a text message this message is rejected.

[00:13:34]Now what happens when seal sender enters into the picture? Well this well this message gets rejected and then what happens when seal sender enters into a picture? Well, what happens is that the seal sender message structure takes the place of the envelope more or less and this is uh also encrypted and the envelope wraps this whole thing and now you will notice that the type becomes unidentified sender which means that it's a seal sender message and the source is of course null however remember that on Android the validation is done by looking only at the envelope header and all of these messages have the same type which is unidentified sender Therefore for Android all of these messages are accepted as a valid message.

[00:14:19]Now you will see for the message in the center in particular that the only layer of authentication is just the seal sender message which we as we said before the server can inject messages on behalf of anybody. Which means that by combining the first capability, the server sending messages as any user and the second one sending just plain text content by passing authentication, a malicious server can send messages on behalf of any user without being detected because there's no safety number notification. Um, and yeah, well more about the attack is that it only affected Android because the validation issue is only for Android. It was fixed more or less one week after disclosure.

[00:14:58]Once again, signal was very quick uh at patching our uh patching the vulnerability and the patching was performed by validating uh properly seal sender plain text messages.

[00:15:12]Now a few comments what went wrong after all the we have we have had years of intense academic attention on signals and despite that these attacks lay undetected. In fact, you can see a lot of analysis about the individual protocols and this is great because this gives us very good guarantees about the individual protocols. However, system level cryptographic security we argue is still a blind spot for the community. We sort of lose the forest for the trees as no said before and it would be nice rather to focus on systems as a whole.

[00:15:47]But the question is do we even have the tools to analyze whole systems? Well, we could have spotted this these attacks earlier using formal analysis, but only but only aha, we're back. Okay, but only if they capture the system in enough detail. So, for example, capturing message types which caused the second attack and only if they capture the interaction between all protocols. For example, the interaction between PNI and SEI protocol, between the Sesame protocol and all that.

[00:16:20]Our techniques do not seem mature enough to capture this level of complexity yet as a cryptographic community. So, we should work on improving this and uh empower the system level cryptographic analysis.

[00:16:34]Is the complexity that we have in signal good? And to answer this question, I have here a picture from Ralph talking at RWPQC. And he shows a slide with all of these features that Signal has in particular in the context of PQC migration. But there's many many more features that Signal has. And I would answer that yes, the complexity as you see in the picture stems from deploying privacy enhancing features and Signal technologically speaking is leading the way in this.

[00:17:02]But with great features come great responsibilities. responsibility to ensure that there's no security regressions and responsibility uh to uh for the community as well to ensure that these protocols that we analyze individually work well together.

[00:17:18]We have some tips from the industry as well. Open source code forces analysis.

[00:17:21]This seems a bit obvious but when we analyze this the signal code this was easy but if we did this for another messenger this will be very hard if it was closed source.

[00:17:31]The documentation that was in the codebase gave us some great insights, but we argue that it could be even better. For example, for the PNI to ACI protocol, we had to extracted its description from the source code ourselves. Therefore, we would argue why not create a way to communicate this boring but still cryptography relevant features to the academic community. For example, the PNI to ACI protocol.

[00:17:55]When we analyzed the uh libraries, we also noticed that lip signal is not the only place where cryptography is is.

[00:18:02]It's also scattered across platform dependent code. And uh this means that the vulnerability was present because the Android version was vulnerable whereas the Apple uh sorry the the the iOS and the desktop versions were not right. and rather why not ensure the cryptographic logic is unified in a single native library where you can have more eyes on it and perhaps prevent some of these issues from happening. And on top of that we have the nice feature that other projects which use the same uh library would not be will be uh can be patched very much more efficiently by simply patching the library and then having all the projects bump their version. In that case we would have then that um all of these are patched immediately and on we which is the opposite of what happened in practice because we had to contact the authors of signance cli and whisperfish to ensure that they patched their version and with this we're open for questions and here's the link to the paper.

[00:19:10]So maybe one quick question before we go into the break or we want all to go to break and get that well desired coffee and take it the questions over there. All right, let's thank our speakers again and see you again.