Instant Delivery Risk Analysis

1

I see DC has introduced FCM Push Notifications for Android and I give my perspective of the risk analysis below, but first I have some questions about this.

  • If I turn off FCM Push in the settings, does this mean my phone will never send my device token to the chatmail server, or will it still send my device token to the chatmail server and just stop the DC notification proxy from sending the notfication to FCM server?

  • If I have already turned on FCM Push in the settings and my device token has already been sent to the chatmail server, will my device token be deleted from the chatmail server when I turn off FCM Push, or will it stay on the chatmail server indefinitely?

  • When I upgrade to the new version of DC with FCM support, will FCM Push be enabled by default, disabled by default, or will I be prompted to choose?

  • I read that support for UnifiedPush and alternative Push providers is currently being considered for future releases. So if the benefit of FCM is that it reliably wakes up background apps while IMAP Push does not (depending on the OS), where does UnifiedPush and alternative Push providers fit into the picture? Do they reliably wake up apps the same as FCM or are they more like IMAP Push in this respect?

I read the following claim on the DC FAQ:

Resulting from this overall privacy design, even the seizure of a chatmail server, or the full seizure of the central Delta Chat notification proxy would not reveal private information that Push services do not already have.

I do not believe this claim is correct. While I appreciate that DC is trying to make DC more convenient for users and DC has put a lot of effort into the privacy design, the FAQ still understates the risk.

Maybe there are aspects of the implementation which I don’t understand, so you can correct me if I’m wrong, but I give some examples below based on my understanding.

Example 1:

Lets say police take interest in an anonymous account because its been used for whistleblowing or activism or whatever. If they seize or subpoena the chatmail server, now they can instantly find out all other accounts used by the same user on the server, which might allow them to both trivially deanonymize the whistleblower/activist account and also start to map personal contacts of the whistleblower/activist.

Therefore the new FCM integration makes it impossible for multi-account users to maintain seperation between accounts and it makes deanonymization easier. Contrary to the claim in the FAQ, the seizure of a chatmail server, or the full seizure of the central Delta Chat notification proxy would reveal private information that Push services do not already have.

Example 2:

If the police also go to Google for information about the push token (and it is well documented that they routinely do this) then they might be able to deanonymize the account (if they haven’t already) if the user has a Google account in their own name or tied to a personal Gmail account, and they can also learn which other apps the user is using.

Again, this can reveal private information that Push services do not already have, contrary to the claim in the FAQ.

With these above examples, I am concerned not only about the immediate risks to users posed by deanonymization and linking accounts but also the fact that chatmail servers and the DC notification proxy will become a more valuable target for seizure.

Example 3:

Google can infer who’s chatting to who and when by correlating the timestamps of push notifications. Obviously this also enables police or governments with access to Google push logs to connect users like this, more efficiently and with need for less resources then they otherwise would (they only need to monitor the central Google push server instead of the whole internet, and they can filter for push tokens sent by the DC push notification proxy).

This can reveal private information even without seizure of a a chatmail server or the DC notification proxy. Without DC’s new FCM integration, Google would not necessarily have this information, and it would be more costly for police and governments to get this information.

So while we can easily recognize the convenience which FCM brings, and we can also acknowledge that DC has made a good effort to mitigate the worst of the risk like exposure of message details, we should also be honest about the risks it poses and accurately inform users about this. This will help users make informed choices according to the level of threat they face and it can help developers and contributors to consider new ways to address the shortcomings of the current design and improve the overall privacy design.

2

hi, if you are serious about security/privacy or a person at risk of such high level, then you could use the F-Droid version of DC that doesn’t contain PUSH notifications and their private blobs from Google inside the APK

3

Google as well as DC would act against the law if assisting in hindering the state authorities, or has intention to support such. Does good Peppa like DC-developers to become and assist criminals? Why not living in tune with ethic and law instead?

May good. holger @hpk delete my persons account and remove all what has been shared and contributed to DC by my person, since not the most slight interest to be anything involved in such undertakings, support and approve of unlawful, anarchy, rebellion and immoral activities.

Instead of serving immoral and working against common security, it would be for oneself and others to use possible well meant founds and taxes to start to educate about basic moral conducts in this it-realm.

Your demo-crazy societies have by nature of majority real and serious problems.

1 Like
4

I didn’t know there was a difference between the F-Droid and Play Store versions, thanks @adbenitez for making me aware of this. I also wasn’t aware that DC has private blobs in the Play Store version, I was under the impression DC was completely FOSS on all platforms and app stores, so this is something I will need to keep in mind in future.

I already use the F-Droid version so I suppose that means I’m not directly effected by the change, but I still seek answers to my questions in the OP so I can give accurate information to others who use the Play Store version and for my own general interest.

5

How do you think police can instantly find out all accounts of a user on any given chatmail server?
Logging happens only in RAM and is auto-removed after a few days.
It’s true that currently the device-token is not encrypted on the chatmail server but we note this in the FAQ already. Given it’s encrypted, there is no immediate way to cross-correlate accounts to a single device.

Note that

  • the notification proxy never knows any e-mail address and neither does Google which only knows the device token to belong to a particular Delta Chat install on a user’s device.
  • the proxy forgets about all tokens after relaying them to Google

Or do you mean that the user has a chatmail account and a gmail account configured in Delta Chat? Even then at the notification-proxy and the google side, the chatmail account is not known, only that a message arrived for some unknown chatmail address.

If your device is tied to Google cloud (a perequisite that FCM push notifications even are enabled and work) then Google has easier ways to know what’s going on in a device, which apps are installed etc. So the main question is what can Google derive from the fact that there is data for the Delta Chat app on a device? As to traffic analysis, i don’t think it’s as obvious as you make it sound that you could reliably find out who chats with whom. Traffic analysis on human chatting activity is harder than someone visiting a website via TOR, which causes a lot of instant machine-generated bidirectional traffic.

1 Like
6

Thank you @hpk for your reply.

Even when encryption is implemented, this depends on how the encryption is implemented. If the encryption of the device token produces the same ciphertext for each account, then its obvious those accounts are of the same user, even if the original device token can’t be known, but if each account uses it’s own unique nonce for encrypting the device token or otherwise guarantees unique ciphertext, then this is not a risk. The fact alone that the device token will be encrypted, as stated in the FAQ, isn’t enough to be reassuring, because it all depends on if each account uses it’s own nonce or not.

And since there is currently no encryption for the device tokens, this should be an opt-in experimental feature IMO, but I also understand DC team is eager to release the feature and I accept that opinions can be different about this.

While logging happens only in RAM, this won’t matter if police seize the DC proxy, because they will then have the decryption key and can decrypt whenever they want all the push tokens they obtain from a chatmail server. I appreciate the measures which DC has taken, like logging only to RAM and (in future) encrypting the device tokens, but these measures do not address all possible threat scenarios.

No, I don’t mean that the user has a chatmail account and a gmail account configured in Delta Chat. I acknowledge the facts you give, that Google by itself does not know the chatmail account, and the DC proxy by itself does not know the gmail account. The problem is when you combine these views, which police can do by seizing or subpoenaing the chatmail server, the DC proxy, and the Google FCM server.

According to Wired:

To identify a person of interest and whom they may have been communicating with, law enforcement must first go to an app developer to obtain the relevant push token and then bring it to the operating system maker—Apple or Google—and request information on which account the token is associated with.

We also know that police are often over-zealous about seizing servers and act in illegal ways, so I don’t think these concerns can be dismissed as theoretical.

You could be right about this in general, and I am not expert in all the ways Google knows what’s going on in a device. My understanding is that a device using FCM with Micro G is not “tied to Google cloud” in a way that lets Google see everything going on in a device, but I could be wrong about this.

The threat comes not only from Google, but also from the police, who can potentially combine the view from Google and the view from the chatmail server and DC proxy through raids and subpoenas.

As to traffic analysis, i don’t think it’s as obvious as you make it sound that you could reliably find out who chats with whom. Traffic analysis on human chatting activity is harder than someone visiting a website via TOR, which causes a lot of instant machine-generated bidirectional traffic.

I don’t want to make traffic analysis sound easy, I don’t think it is easy, but I also don’t want to underestimate the sophistication of well resourced attackers and the availability of commercialy available tools for attackers ready to buy, especially in the age of surveilance capitalism.

A single message probably isn’t enough for traffic analysis to work, but the risk is when many messages are exchanged over a long period of time, which provides enough data points for the correlation attack, so its a bit different to visiting a website, although read receipts also cause instant machine-generated bidirectional traffic and lower the number of messages needed for a successful attack. It probably isn’t 100% reliable, but it doesn’t need to be 100% accurate to be a risk and it doesn’t stop attackers from employing this technique anyway.

Amnesty International’s Security Lab has a report on this:

As internet traffic was increasingly encrypted, companies such as Nexa group started to offer new product lines such as JASMINE, which focused on analysing the metadata of encrypted traffic apps with a particular focus on messaging applications …

The JASMINE documentation also explains that by analysing encrypted traffic “events” for a whole country – in mass interception mode – JASMINE has the ability to correlate and identify the participants in encrypted group chats on messaging apps, with specific support analysing WhatsApp chat conversations.

Such a metadata analysis system can record the distinctive network traffic pattern each time a phone receives a new encrypted message or notification from a chat application such as WhatsApp or Telegram. Over time, with dozens or hundreds of messages received, the correlation between these notification events for multiple individuals will get stronger.

Eventually these systems can, with a high degree of confidence, determine which phones in the country are consistently receiving a notification at the same time, therefore indicating the phones and individuals which are likely members of the same encrypted messenger chat group. Recent reporting from the New York Times revealed how states, for example Russia, are developing and deploying similar internet traffic analysis systems to track the users of encrypted messaging applications in the country.

This is not an abstract risk; other commercial surveillance vendors such as Sandvine have reportedly developed and advertised similar surveillance capabilities to government customers such as Algeria and Belarus.

An internal threat assessment by WhatsApp’s security team has also highlighted this danger and refers to “ongoing exploitation of traffic analysis vulnerabilities that make it possible for nation states to determine who is talking to who”.

Obviously its not just DC which is effected. WhatsApp, Signal, and Telegram all are vulnerable. Until now DC and other common messaging apps don’t consider traffic analysis part of they’re threat model, but I think its something we need to talk about more, because it doesn’t seem reasonable to exclude it from the threat model.

Amnesty International’s Security Lab recommends:

To defend against traffic correlation attacks, messaging apps and push notification services should consider traffic correlation attacks as practical real-world attacks which are deployed against their users and include this in their threat models.

I know there is no quick and easy solution, and its a very complex problem, but sooner we acknowledge and discuss the problem, sooner we can work toward addresing it and maybe creating long term solution.

A comprehensive solution would probably involve multiple mitigation techniques and take a lot of time to implement and maybe also make some things less convenient for users, but there are also some things which would be easier and quicker to implement with minimal inconvenience for users, for example introducing random delays for read receipts. With discussion about the topic we can get different viewpoints and find the right balance to address the needs of privacy, convenience and developer resources.

Well resourced attackers can carry out traffic analysis attacks even without FCM, but for the reasons I gave above, I think FCM lowers the bar for these sorts of attacks. And my second example shows FCM can help police deanonymize accounts even without any traffic analysis.

I do appreciate the thought put into the existing privacy design and I do think its better then many other messaging apps, but I also think DC plays down the risk when it implies that instant delivery with FCM does not create any additional risks, and I also think that more discussion of topics like traffic analysis (with and without FCM) is needed, even if its a difficult topic.

1 Like
7

Can the chatmail provider modify the server to log the users’ device tokens in plaintext and thereby determine which users are associated with which account? I think that that’s an important thing to note in the FAQ.

8

I think one thing that might be useful might be to automatically create multiple chatmail accounts per user, and each chatmail account would have its own encryption key. When a user adds another user, the other user will share their secondary accounts’ email addresses and encryption keys, so the first user can SecureJoin with the secondary accounts. Then we might be able to randomly select from our pool of secondary accounts which account to send the message with, so that it’s harder for automated traffic analysis to identify social graphs. Additionally, creating more secondary accounts at random times and deleting old secondary accounts could make it even harder for automated traffic analysis.

1 Like
9

If the setting is disabled, Delta Chat will not try to obtain FCM token from the operating system. This check however happens during the application start, so when you register an account the setting is usually enabled. You will have to create a profile and then disable the setting, then probably delete this temporary profile. I opened an issue about this, I think it is a bug that user cannot change the setting before creating a profile:

The token will be removed as soon as chatmail server tries to use it and fails e.g. because it is expired.

I think it is enabled by default on Google Play version. In F-Droid version FCM push is disabled and cannot be enabled.

FCM integration definitely does not make it impossible, because even without FCM it is better to use separate devices and separate network connections if you really want you accounts to be unlinkable.

This is true that if the token linked to account is obtained, Google may be asked to reveal which Google account it is connected to. Would like a reference to “it is well documented that they routinely do this” though.

1 Like
10

Cool idea @ethanc8 having a pool of randomly generated secondary accounts for reach contact, I like this thinking, although I suspect it could be difficult to develop the feature and it also requires thinking about how to hide the added complexity from users within a simple and manageable UI.

For reference, Amnesty International’s Security Lab has also provided examples/suggestions of some mitigations in the report I quoted above:

Some simple mitigations such as small timing delays in notifications, adding cover traffic or sending fixed size messages may help to significantly weaken the accuracy of these types of attacks. More open research is needed to analyse possible mitigations against these correlation attacks.

Thank you @link2xt for your answers, this is very helpful for people who are cautions about FCM to know in which conditions DC does and does not send the device token. These details are not obvious to normal users, so you’re answers provide clarity about this.

11

Thanks a lot for your thoughts and considerations. This is being discussed further among involved developers and i think at least we need to update the FAQ but probably also think about how to evolve push notification support. If in doubt, one can today create an account, disable FCM, remove account, then create another account (that will not use FCM because it’s currently a global setting) and be sure that no one can make a connection between this new e-mail address and the device token and thus not ask google for revealing who is behind an e-mail address.

1 Like
12

You need to restart the app after disabling notifications in the settings. Or restart the phone to be sure.

1 Like
13

Thanks again @hpk and @link2xt for the advice about the workaround and for the update about response from the DC team. It is good to know that DC team will discuss the issues raised here.

Maybe I phrased this incorrect. What I mean is that FCM integration adds another method for correlating accounts which did not exist before. This method is trivial to exploit if device tokens are not encrypted on chatmail servers or if the encryption does not use a unique nonce for each account, and harder but not impossible to exploit if device tokens are encrypted with a unique nonce.

But you are correct this is not the only method for correlating accounts. If I understand correctly the other methods for correlating accounts can be mitigated with some current methods like disabling background sync on platforms which support this (hopefully available to all platforms in future) or in the future if DC isolates the Tor circuit for each account.