Secure push notifications: from theory to practice
Hello, Habr!
Today I’ll talk about what my colleagues and I have been doing for several months: about push notifications for mobile instant messengers. As I said, in our application the main emphasis is on security. Therefore, we found out whether push notifications have “weaknesses” and if so, how can we level them in order to add this useful option to our service.
I am publishing a translation of our article with Medium with a few additions from myself. It contains the results of the “investigation” and a story about how the problem was solved.
In the classic model, push notifications make messengers vulnerable to MITM attacks (Man-in-the-middle, Man in the Middle). For example, with 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 an opportunity for reading by third parties. The authors of the article “Encrypt Wisely” on Xaker.ru, devoted to message encryption methods, discussed this possibility in more detail .
If you think that Apple and Google’s servers will not allow 100% leakage of user encryption keys, consider that their employees have access to them. And the employees are people.
With all the vulnerabilities of pushing, many "safe" messengers, including Signal and Telegram, use them. Otherwise, users will have to "manually" monitor new messages by constantly entering the application. Which is very inconvenient, and competing messengers will get an advantage.
In our project, we came to grips with this issue several months ago. We needed to make push notifications an option to be competitive. But at the same time, do not make a hole in the security, 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, and the interlocutor’s public keys are available on the blockchain to protect against MITM attacks.
In the first version of the push, we decided to play it safe as much as possible and not transmit the message text at all. The push service received from the node not the message text, 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.
How it worked: video .
After that, we learned that the latest version of notifications from Apple has new security features. They released the UNNotificationServiceExtension, which allows developers to send fully encrypted notification data through APNS. Then the application on the end-user device decrypts (or downloads additional data) and displays a notification. We took it as the basis of the second version of the push.
Now we have developed the second version of push notifications for iOS, which allows you to display message text without a security risk. In the new concept, the logic looks like this:
We took this version as working and implemented it in the latest update of the iOS application.
Those interested in the technical side can see the source code: github.com/Adamant-im/adamant-notificationService .
Today I’ll talk about what my colleagues and I have been doing for several months: about push notifications for mobile instant messengers. As I said, in our application the main emphasis is on security. Therefore, we found out whether push notifications have “weaknesses” and if so, how can we level them in order to add this useful option to our service.
I am publishing a translation of our article with Medium with a few additions from myself. It contains the results of the “investigation” and a story about how the problem was solved.
Explore the materiel
In the classic model, push notifications make messengers vulnerable to MITM attacks (Man-in-the-middle, Man in the Middle). For example, with 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 an opportunity for reading by third parties. The authors of the article “Encrypt Wisely” on Xaker.ru, devoted to message encryption methods, discussed this possibility in more detail .
If you think that Apple and Google’s servers will not allow 100% leakage of user encryption keys, consider that their employees have access to them. And the employees are people.
With all the vulnerabilities of pushing, many "safe" messengers, including Signal and Telegram, use them. Otherwise, users will have to "manually" monitor new messages by 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 several months ago. We needed to make push notifications an option to be competitive. But at the same time, do not make a hole in the security, 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, and the interlocutor’s public keys are available on the blockchain to protect against MITM attacks.
In the first version of the push, we decided to play it safe as much as possible and not transmit the message text at all. The push service received from the node not the message text, 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.
How it worked: video .
After that, we learned that the latest version of notifications from Apple has new security features. They released the UNNotificationServiceExtension, which allows developers to send fully encrypted notification data through APNS. Then the application on the end-user device decrypts (or downloads additional data) and displays a notification. We took it as the basis of the second version of the push.
Now we have developed the second version of push notifications for iOS, which allows you to display message text without a security risk. In the new concept, the logic looks like this:
- The push service sends a push notification with a transaction number (the encrypted message can be very large, and the size of notifications is very limited)
- Upon receipt of a notification, the device starts our NotificationServiceExtension - a micro application that requests a transaction from the node by id, decrypts it using the saved passphrase, and gives the system a new notification. Passphrase is stored in a secure warehouse.
- The system displays a notification with a decrypted message or translation.
- The keys do not go anywhere, as does a plain text message. The push service does not have the ability to decrypt the message.
We took this version as working and implemented it in the latest update of the iOS application.
Those interested in the technical side can see the source code: github.com/Adamant-im/adamant-notificationService .