Secure push notifications: from theory to practice
Hi, Habr!
Today I’ll talk about what my colleagues and I have been busy with for several months: about push notifications for mobile messengers. As I said, in our application, the main focus is on security. Therefore, we found out whether 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 the translation of our article with Medium with a few additions from myself. In it, the results of the “investigation” and a story about how they solved the problem.
')
In the classic push notification model, instant messengers are made vulnerable to MITM attacks (Man-in-the-middle, Man in the Middle). For example, in Google, Microsoft, and in the old version of iMessage, the application sends encryption keys to Apple’s servers — user authentication and decryption of the message header (or its content) takes place on the server.
As a result, there is a chance to read the correspondence, getting access to the server push-notifications. And this means that any encryption of correspondence is useless: push notifications will still leave room for reading by third parties. This opportunity was discussed in more detail by the authors of the article “Enumerate Properly” on Xaker.ru, which deals with the methods of encrypting messages.
If it seems to you that the Apple and Google servers will not allow 100% of the encryption keys for users to be leaked, consider that their employees have access to them. And the employees are people.
With all the vulnerabilities push, many "safe" instant 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 instant messengers will have an advantage.
In our project, we closely tackled this issue a few months ago. We needed to make the push notifications option to be competitive. But at the same time not to turn a hole in security, because any data leakage will undermine the credibility of the project.
However, we already have an important advantage: our messenger is decentralized (the data is stored in the blockchain), and the employees do not have access to their accounts. Only users have encryption keys, and interlocutors' 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 to transmit the message text at all. Push service received from the node is not the message text, but only a signal about the fact of its receipt. Therefore, the user saw the notification "A new message arrived." It was possible to read it only in the messenger.
How it worked: video .
After that, we learned that there are new security elements in the latest version of Apple's notifications. They released UNNotificationServiceExtension, which allows developers to send fully encrypted notification data through APNS. Then the application on the end-user device performs the decryption (or downloads additional data) and displays a notification. We took it as the basis for the second version of the push.
Now we have developed a 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:
We took this version as working version and implemented it in the latest update of the iOS application.
Those interested in the technical side can view the source code: github.com/Adamant-im/adamant-notificationService .
Today I’ll talk about what my colleagues and I have been busy with for several months: about push notifications for mobile messengers. As I said, in our application, the main focus is on security. Therefore, we found out whether 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 the translation of our article with Medium with a few additions from myself. In it, the results of the “investigation” and a story about how they solved the problem.
')
Investigate materiel
In the classic push notification model, instant messengers are made vulnerable to MITM attacks (Man-in-the-middle, Man in the Middle). For example, in Google, Microsoft, and in the old version of iMessage, the application sends encryption keys to Apple’s servers — user authentication and decryption of the message header (or its content) takes place on the server.
As a result, there is a chance to read the correspondence, getting access to the server push-notifications. And this means that any encryption of correspondence is useless: push notifications will still leave room for reading by third parties. This opportunity was discussed in more detail by the authors of the article “Enumerate Properly” on Xaker.ru, which deals with the methods of encrypting messages.
If it seems to you that the Apple and Google servers will not allow 100% of the encryption keys for users to be leaked, consider that their employees have access to them. And the employees are people.
With all the vulnerabilities push, many "safe" instant 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 instant messengers will have an advantage.
Paranoia and common sense
In our project, we closely tackled this issue a few months ago. We needed to make the push notifications option to be competitive. But at the same time not to turn a hole in security, because any data leakage will undermine the credibility of the project.
However, we already have an important advantage: our messenger is decentralized (the data is stored in the blockchain), and the employees do not have access to their accounts. Only users have encryption keys, and interlocutors' 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 to transmit the message text at all. Push service received from the node is not the message text, but only a signal about the fact of its receipt. Therefore, the user saw the notification "A new message arrived." It was possible to read it only in the messenger.
How it worked: video .
After that, we learned that there are new security elements in the latest version of Apple's notifications. They released UNNotificationServiceExtension, which allows developers to send fully encrypted notification data through APNS. Then the application on the end-user device performs the decryption (or downloads additional data) and displays a notification. We took it as the basis for the second version of the push.
Now we have developed a 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 (the encrypted message can be very large, and the size of the notifications is very limited)
- When receiving a notification, the device launches our NotificationServiceExtension, a micro application, which requests a transaction from the node by id, decrypts it with a saved passphrase, and gives the system a new notification. Passphrase is stored in a secure vault.
- The system displays a notification with a decrypted message or translation.
- Keys do not go anywhere, like a plain text-message. The push service does not have the ability to decrypt the message.
We took this version as working version and implemented it in the latest update of the iOS application.
Those interested in the technical side can view the source code: github.com/Adamant-im/adamant-notificationService .
Source: https://habr.com/ru/post/456902/
All Articles