Anti timing attack features #14463
Anti timing attack features #14463
Conversation
… timing attack methods
for some reason ONLY the android client (NOT the ios client) sends delivered to blocked users -- this is really bad and can be used for profiling
|
this is good fun! If the server can see the sender, it will send a receipt. Ironically, it doesn't send a receipt until the client is online. Exposing you are online. This is also a problem that should be fixed!!!
These show up in the ui. It's inconsistent to disable them.
Again, if the server can see the sender, it sends a receipt. This will commonly be the case with blocked senders. When the server cannot see the sender no receipt is sent to blocked senders on Android. You don't need all those options; when might someone prefer instant receipts? Consider removing the minimum delay so instant can be chosen at random. |
Are you referring to the Signal servers?
Yes, it should be an optional toggle, and it should be clear how it will affect UX for the other users. I'll consider ways to drop the time add minimum to 0, or perhaps make the delay an optional range. |
|
Disabled delivered receipts are enabled by default for reactions+deletes as these don't affect UX at all |
If you ensure Allow from anyone in Settings>Privacy>Advanced is off for the test device, ensure both devices don't share group membership, block Device 1 and then edit the message you'll have a different result. Show status icon is on by default I believe in the same section of settings. On Device 1, If you look at "Message details" for the message to be edited you'll see the icon. Then once you edit the message it'll vanish. If Device 1 can prove it has the test device's current profile keys, the server cannot see that Device 1 sent a message to the test device. https://signal.org/blog/sealed-sender#:~:text=Delivery%20tokens Blocking rotates test device's profile key meaning Device 1 will only receive server receipts, nothing directly from the test device. if Allow from anyone is on, Device 1 doesn't need test device's profile keys. |
|
Interesting, you're right, so this only works when the attacker is using sealed sender, and an attacker is most likely to not use sealed sender lol... so is there no way to patch that on the client end? Is this a protocol issue? |
This is good but not perfect, is make the phone delay distribution much less obvious by adding a lot of variance and shifting the mean by 2.65 seconds but with enough data points you could still statistically estimate the mean over a period and compensate for both the added variance and the shift of the distribution. The new distribution is now a sum of the 'true' distribution (delay from the phone) that we want to hide, and the 'fake' distribution the random 0.3 to 5 second delay. By modelling the coupled distribution you can get estimations of the real distribution of timings from the device and be able to defeat the random delay mitigation. There is 2 possibilities to fix it:
How to compensate:
This way it's no longer possible to mesure d and hence do the exploit. Note: the graphs on the paper observe maximum delays of about 3 seconds, this should become the lower bound of the delay instead of 0.3 sec, so 'r' should be sampled form a uniform distribution ranging from 3 to 5 second. Note 2: The exploit might still be possible after this if queued responses are also being delayed differently depending the device state (I don't know how if it's the case), in which case estimation of the full delay is needs to be compensated which is harder to do preciselly. My hypothesis (that need to be verified empirically before implementation) for a simple estimation of that full delay could be the double of 'd' initally estimated changing the last step "to delay the message by : r - 2*d". |
|
Finally I would recommend contacting the original authors of the papers once you have some good mitigations in place so that they can verify it by testing it in practice on the same devices used for their research, as they likelly already have code for that kinds of mesurements. |
|
If the intent is protection from traffic analysts @sullystuff this seems effective. Signal might implement it in a more joined-up, rigorous and thorough way. They should also fix that server-side issue I mentioned too. |
|
What I'd like to suggest is to merge the random delay as is, for 2 reasons:
At the same time, a second cross platform issue/tracker that also include protocol discussion should be created to discuss how to best make the entire attack completely impossible. |
|
Finally after thinking it over, it might much easier to mitigate server side. This does place more trust in the server as the server would be able to collect all the data for the exploit. But the server can easily compute the full exact RTT of your device and correct for it when sending the read indicator back to the attacker. |
|
@Lama-Thematique Sure, it's easier to mitigate server-side, but as you stated that places more trust in the server when we're trying to avoid that (imo)
Yes, over a long enough period of time an attacker could, in theory, be able to calculate away the noise. I think the best trustless solution here is to adjust the min/max delays on a per-device/OS-version basis, as reported by those researchers. I'll do my best to get in touch with them. |
|
I've sent an email to one of the researchers, I'll update here if I get a response, and if I don't I'll reach out to a few more. |
It's tradeoffs as:
Tho i agree that i would prefer a solid trustless implementation. Trustless solution are great because it's trustless but could not entirely hide the distributions correctly as it's based on estimations of RTT. Implementation needs to be carefull to have good unbiased estimates of the true RTT distribution in all situations (4g/wifi, different OS and version, different hardwares, different background/foreground tasks, etc...) otherwise better data anlysis could bring back the problem.
This is a bad idea IMO at it requires constant maintenance for the table of devices and OS versions and could still be affected by other factors. For trustless solutions I think heuristic based methods are preferable meaning device estimates it's own RTT by itself. In all, my preferences (and this is a opinion so it's debatable) are: |
|
We can probably automate tests on the client to measure the average time to perform return pings (standby, app foreground, app background, active phone call etc) and adjust the delay by the measured average time per state. That will take a while to write though. |
|
@greyson-signal @alex-signal thoughts? |
|
Hey there, I’m one of the authors of the paper you referred to. We’re happy to see progress being made to mitigate the issue. We fully agree that having no solution is the worst option, but finding a “real fix” is also quite tricky. As you already noted, there are things which can be done with relatively little effort, though:
Keep in mind, this will not be a solution against the various "is online" side-channels, but make it harder for an attacker to extract more information from receipts. In the long run, other solutions can be considered. These might also include a discussion about whether explicit delivery receipts are needed at all, or whether they could be disabled by privacy-sensitive users. From our current understanding, delivery receipts mainly serve the purpose of allowing the sender to clear their send queue and handle certain edge cases. But we would love to have a more detailed discussion about whether it might be possible to get rid of them completely. Maybe it is enough to implicitly acknowledge received messages only when an explicit reply is sent, for example? |
|
Thanks for your feedback, @kernoelpanic. It's great to see one of the authors of the paper acknowledging some of the limitations with the approaches that have been presented. The assumption that delivery receipts are mostly unnecessary couldn't be further from the truth. The reality is that they serve several important functions that significantly enhance security, and they are a crucial feature that users expect to work as quickly and reliably as possible. The vast majority of delivery receipts on Signal are sent as end-to-end encrypted messages that are completely opaque to the service. If you know someone's profile key, and are therefore able to exchange messages with them using sealed sender, then you can also send each other delivery receipts that look just like normal e2ee message traffic. One of the hallmark features of the Signal Protocol is that message keys "ratchet" forward, with each message encrypted by a new and unique key. Because delivery receipts can be encapsulated in a standard Signal message, just like a handcrafted reply, they can also advance the ratchet. This is a substantial improvement that enables key material to rotate far more frequently than it would otherwise. In the case of transient errors, Signal clients can also ask each other to re-send a message that wasn't delivered successfully. The delivery receipts act as an important checkpoint in this context. Once a message has been delivered, the client can safely ignore any requests to re-deliver the same message. Dropping delivery receipts "for actions that do not trigger observable notifications" (for example, a reaction to someone else's message in a group chat) would make this entire line of defense far more complicated and error-prone. In the case of a fast-moving conversation, a delay of up to 5 seconds before delivery receipts are sent would negatively affect the perceived and actual performance of the app in ways that would harm the user experience and that could lead people to choose less secure alternatives. In order to maximize battery life, mobile platforms place extraordinary limitations on the amount of background processing that apps can perform. Introducing randomized client-side delays could easily result in situations where background processes are killed by the OS before a delivery receipt can be sent. Those receipts could be delayed until additional messages are received (and therefore the app gets another limited execution window) or held up until the app is launched into the foreground. Whenever those situations inevitably occurred, the sender would perceive Signal as being broken and slow. It simply isn't a tenable suggestion, from either a UX or technical perspective. Introducing these delays on the server-side doesn't address the UX issues at all, and as people have already pointed out in this thread it could increase the scope of the metadata that's stored on the service which is something we don't want to do. The Signal service strives to retain as little metadata as possible, and also goes to great lengths to avoid having access to any sensitive information in the first place. The only way to do this is for the app to process end-to-end encrypted messages directly on your own device instead of our servers. Regarding potential "Resource Exhaustion Attacks" via delivery receipts in Signal, we think it's important to emphasize this quote from the paper:
Many of our competitors store plaintext messages in a database, and they can send message content directly to Apple and Google for efficient push notification delivery that requires zero background processing on your phone. You don't need to wake up an app to decrypt a message if it wasn't encrypted to begin with. These apps will never be mentioned in any papers discussing end-to-end-encrypted delivery receipts and resource exhaustion, but that doesn't make them more secure. Quite the opposite. For people who want to restrict delivery receipts, Signal already supports disabling phone number discoverability (Settings > Privacy > Phone Number > Who Can Find Me By Number). With this setting enabled, you can choose a random alphanumeric username and no one will be able to send you any messages (delivery receipts or otherwise) unless you share that username with them. |
|
@greyson-signal thanks for your thoughts, but what about timing attack vulnerabilities? Resource exhaustion isn't a problem, sure, but timing attacks can presently be used to analyze users' behavior. Is there really absolutely no way to mitigate this? |
5 participants
First time contributor checklist
Contributor checklist
Fixes #1234syntaxDescription
Add privacy features to prevent timing attacks as detailed here
Tested with iOS 26.1 on iPhone 16 Pro as well as Windows 11 for the sending client, and aforementioned Android mobile device for the receiving client (with this modified apk)