Hey Habr!
Today I’ll tell you about what my colleagues and I have been doing for several months now: about push notifications for mobile messengers. As I said, in our application, the main emphasis is on security. Therefore, we found out if push notifications have “weak points” and, if so, how we can level them in order to add this useful option to our service.
I publish a translation of our with a few additions from myself. It contains the results of the “investigation” and a story about how the problem was solved.
Exploring the materiel
In the classic model, push notifications make messengers vulnerable to MITM (Man-in-the-middle) attacks. For example, at Google, Microsoft, and in the old version of iMessage, the application sends encryption keys to Apple servers - users are authenticated on the server and the message header (or its content) is decrypted.
As a result, there is a chance to read the correspondence by gaining access to the push notification server. And this means that any encryption of correspondence is useless: push notifications will still leave the possibility for reading by third parties. This possibility was discussed in more detail by the authors of the article. on Xaker.ru, dedicated to message encryption methods.
If it seems to you that Apple and Google servers will 100% prevent users' encryption keys from leaking, consider that their employees have access to them. And employees are people.
With all the vulnerabilities of push notifications, many "safe" messengers, including Signal and Telegram, use them. After all, otherwise users will have to "manually" monitor new messages, constantly entering the application. Which is very inconvenient, and competing messengers will get an advantage.
Paranoia and common sense
In our project, we came to grips with this issue a few months ago. We needed a push notification option to be competitive. But this does not open a security hole, because any data leakage will undermine the credibility of the project.
However, we already have an important advantage: our messenger is decentralized (data is stored on the blockchain), while employees do not have access to accounts. Only users have encryption keys, while the public keys of the interlocutors are available on the blockchain to protect against MITM attacks.
In the first version of push notifications, we decided to play it safe as much as possible and not send the text of the message at all. The push service received from the node not the text of the message, but only a signal about the fact of its receipt. Therefore, the user saw the notification "A new message has arrived." It was possible to read it only in the messenger.
.
After that, we learned that the latest version of notifications from Apple has new security features. They UNNotificationServiceExtension which allows developers to send fully encrypted notification data via APNS. The application on the end user's device then performs the decryption (or downloads additional data) and displays a notification. We took it as the basis for the second version of push notifications.
We have now developed the second version of push notifications for iOS, which allows you to display the text of the message without security risks. In the new concept, the logic looks like this:
- The push service sends a push notification with the transaction number (encrypted message can be very large, and the size of notifications is very limited)
- When a device receives a notification, it launches our NotificationServiceExtension - a micro-application that requests a transaction from the node by id, decrypts it using the saved passphrase, and sends a new notification to the system. The passphrase is stored in secure storage.
- The system shows a notification with the decoded message or translation.
- The keys don't go anywhere, just like a plain text message. The push service has no way to decrypt the message.
We took this version as a working version and implemented it in the latest update of the iOS app.
Those interested in the technical side can see the source code: .
Source: habr.com