Discovery: anonymization of FCM tokens to prevent grouping inboxes by owner

[kaladivo]

Current problem

We need to push messages to the device for core features to work. The most important features are:

• Trigger offer encryptions - when new user phone number creates an account we need to send push notifications to users that have that phone number in their social network to encrypt and update offer (if any) for that user. This needs to be done when the app is in background.
• Chat messages - receiving chat messages relies heavily on push notifications
  • Pushing system notifications when the app is on background to notify user via system notification
  • Pushing system notifications when the app is on foreground to fetch new message from server - this is much better approach then periodically pulling messages since it does not put unnecessary stress on the server. So far it works reliably although the app still pulls messages as a backup.

Core of the problem

We use firebase messaging service (FCM) to issue push notifications (FCM is Android Native & uses APNs- Apple Push Notifications Service - for iOS). Notifications are issued from server. For server to issue push notification using FCM we need the following:

• Server credentials to authenticate as our backend to FCM
• FCM token of the device (this is generated for our app which is again authenticated by Firebase)
  • For each app installed on the device the FCM token is different. Token can be invalidated, regenerated and expires after 30days or so.
  • Token is unique to app instance android, ios

For each user, notification tokens need to be stored in database, in our model we store them in 2 places

• Contact db - users table - this token is used for sending network updates to device (when new phone number loggs in)
• Chat db - inbox table - each inbox contains fcm token to send new messages notifications to

Our aim is to make inboxes anonymous and make it impossible to link multiple inboxes to one user. Currently it is possible to do that using fcm token.

Main constraint in this regard is the sending of push notifications. Server needs to handle the notification payload - which is encrypted - and notification token to to FCM.

Currently there are following informations sent with a chat notification:

• TITLE + BODY (dummy text fallback - "you have received a chat message")
• TYPE - type of the notification such as REQUEST_MESSAGING , TEXT_MESSAGE...
• INBOX - Public key of the target inbox
• SENDER - public key of sender inbox
• PREVIEW - encrypted notification preview

Encrypting FCM - Possible solution that still utilises FCM (and APNS on iOS)

We need to find a way how to prevent linking multiple inboxes to one user. There are following constraints that the solution needs to meet:

• Plain FCM token should not be stored in chat database
• Plain FCM token should not be sent to other users (to prevent them from grouping inboxes locally)
• Server needs to have a way how to get plain FCM token when issuing notification.
• Server needs to have a way to verify that the FCM token really belongs to the inbox - this prevents user sending messages to inboxes that did not approve messaging.

The token in chat database can be Symmetrically encrypted with a secret. For every inbox, client will encrypt the fcm token with symmetric key and send it to the server. Server will store it with other inbox metadata. Created inbox should be stored as follows:

Client side (inbox owner):

• Cypher key
• Plain FCM token

Server side:

• Inbox address
• Encrypted FCM token

When another client wants to send notification to the client, he first needs have the cypher key. Which he will send to the server together with payload which will server use to decrypt the FCM token cypher and issue the notification. Cypher key can be included in public payload of the offer.

The problem here is, that eventually server needs to have plain FCM Token and target inbox public key to send the notification. This still makes it possible for server to group inboxes by fcm token (albeit it is more complicated since it can't be done from the database data).

The way how to solve this is removing public keys from notification payload.

Messaging connections not inboxes (PoW draft, this needs to be refined further)

Each connection represents open channel. There is no information about public keys associated with connection. This is rough connection shape stored in database (admin id can be replaced by mor sophisticated signature system):

• UUID
• FCM cyphers - Set containing 2 elements
• Admin Ids - set containing 2 elements

Sending messages A -> B:

• A sends POST request:
  • UUID
  • Admin id
  • fcm cypher
  • message payload (encrypted)
• Server decrypts FCM token and checks if connection exists
• Server sends notification with payload:
  • connection UUID
  • FCM token key of other side
  • Message uuid
  • Message payload (encrypted)
  • admin id
• Server saves the chat message into messages table (todo: owner of message - who can remove it?):
  • Message payload
  • Connection UUID
  • Message uuid
• B can pull the messages with post:
  • connection UUID
  • connection admin id

Opening connection A -> B: TODO

Alternate solution - ditching FCM messaging all together

• https://www.process-one.net/blog/my-gsoc-2015-project-push-for-xmpp/

Basically, instead of using APNS we can open a socket and have server push messages though. This is very straightforward to do on android using foreground services.

On iOs this is problematic.

It currently seems there is no way to keep socket connection active (or at least have the app react to incoming messages).

From old ios 4 documentation:

[kaladivo]

Final solution

This is not a proposal to rewrite of chat microservice! This is just a way how to remove FCM tokens to inboxes table from the database.

It is possible to implemented and release this solution without breaking compatibility to previous versions!

Overview

FCM token will be encrypted and stored into offer's public payload using ECIES with server public key. To send chat message, 2 operations should be done - ideally separated so they can not be linked:

1. Issue notification to receiver
2. Send encrypted message to server

Providing FCM token to other clients

1. Get server public key (either from build time constant or by http get)
2. ECIES encrypt local FCM token using server public key
3. Add cipher text to offer public payload
4. Treat FCM token update as offer update (just reupload public payload)

Updating FCM token in open chats

This needs o be done since chats are only "weakly" linked to offers. Offer for chat can already be removed.

Sender

1. Creates token ciphertext
2. Sends chat message with updated cipher text to all open chats

Reciever

1. Recieves update
2. Updates fcm token cipher text for the chat

Issuing notification to receiver

Client sender:

1. Get FCM token cipher text from public payload of the offer
2. Encrypt notification payload and send POST with {"notificationPayload": cypherText, "fcmcipher": fcmTokenCypherText} - Notification payload should be treated at potentially dangerous, there is no validation that the data are from verified author

Server:

1. Decrypt cypher into FCM token and issue notification with provided payload + fcm token ciphertext. Server should not recieve any other information about the message.

Client receiver:

1. Receive FCM message with payload
2. Find inbox keypair by matching fcmcipher in notification payload with fcmcipher in published offers.
3. (Decrypt encrypted payload with private key - Notification payload should be treated at potentially dangerous, there is no validation that the data are from verified author.)
4. Fetch messages for the inbox.
5. Display notification

Sending encrypted message to server

Sending / receiving messages is beyond scope of this change set. This is just a simplified description of how it it's currently done.

Client sender:

1. Encrypt message
2. Call http post with: a. Encrypted payload b. Validated public key of sender

Server:

1. Validate public key of sender
2. Save encrypted message to db
3. (Ideally remove messages after set amount of time has passed #301)
4. ! Do not send notification if sender client indicates that it is capable of calling notification microservice (in client-version header)!

Client receiver:

1. Call get messages for public key
2. decipher message payload
3. Call remove seen messages to clear from server

Caveats

• New key pair for server should be generated and use only for FCM tokens
• With this approach anyone can send message to anyone - client needs to filter out the messages
• Dumb service for sending notifications should be created - let's NOT put this logic to existing chat service
• Encrypting the same token should return different cypher text every time - ECIES should add random element into the cypher text by default.
• If user disabled notification there won't be notification token in public payload.

Questions

• How to separate sending notification call from sending message? - time randomization is not reliable.
• How to tell for which inbox is the notification payload addressed without revealing metadata about communication?
  • Send encrypted fcm token in payload of the notification - it can later be looked up by receiving client in published offers.
• How to ensure that the notification sender is who he says he is?
  • It can not be done. Notification should serve only as a refresh trigger.
  • Do we really need notification preview sent in notification payload? Reciever can simply fetch data form the server when they receive the notification.
• How to prevent spam attacks ? How to implement rate limiting so ios/android system is not throttling background actions?

Proposed changes to be made

See list of tickets in here: https://github.com/vexl-it/vexl/milestone/10

[kaladivo]

• Server should be able to change the key
• rate limiting based on both plain FCM token / encrypted - do not allow sending more than X messages per Y time.