Здравей, Хабр!
Днес ще ви разкажа за това, с какво сме заети с колегите през последните месеци: за push уведомленията за мобилни мессенджъри. Както вече споменах, в нашето приложение основният акцент е поставен върху сигурността. Затова проучвахме дали push уведомленията имат "слаби места" и ако да, как можем да ги неутрализираме, за да добавим тази полезна опция в нашия сервис.
Публикувам превод на нашата с малки добавки от мен. В нея са обобщени резултатите от "разследването" и разказано как решихме проблема.
Изследваме материята
В класическия модел push уведомленията правят мессенджрите уязвими за MITM атаки (Човек в средата). Например, при Google, Microsoft и в старата версия на iMessage приложението изпраща ключове за шифроване на сървърите на Apple — на сървъра се извършва удостоверяване на потребителите и декодиране на заглавието на съобщението (или съдържанието му).
В крайна сметка има шанс да се прочете кореспонденцията, ако получим достъп до сървъра за push уведомления. А това означава, че каквото и да е шифроване на кореспонденцията, е безполезно: push уведомленията пак оставят възможност за четене от трети лица. По-подробно тази възможност обсъждат авторите на статията на Xaker.ru, посветена на методите за шифроване на съобщения.
Ако ви се струва, че сървърите на Apple и Google 100% няма да позволят изтичане на ключове за шифроване на потребители, помислете, че техните служители имат достъп до тях. А служителите - те са хора.
При всички уязвимости на push уведомленията, много "сигурни" мессенджъри, включително Signal и Telegram, ги използват. Защото в противен случай потребителите ще трябва „ръчно“ да следят новите съобщения, постоянно влизайки в приложението. Което е доста неудобно и конкурентните мессенджъри ще получат предимство.
Параноя и здрав разум
В нашия проект се заехме с този въпрос преди няколко месеца. Трябваше да внедрим опция за push уведомления, за да сме конкурентоспособни. Но в същото време не искахме да пропуснем дупка в сигурността, защото всяко изтичане на данни ще подкопае доверието в проекта.
Впрочем, вече имаме важно предимство: нашият мессенджър е децентрализован (данните се съхраняват в блокчейн), а служителите нямат достъп до акаунтите. Ключовете за шифроване са само у потребителите, а публичните ключове на събеседниците са достъпни в блокчейн, за да предпазят от MITM атаки.
В първата версия на пуш известията решихме да се застраховаме максимално и изобщо да не предаваме текста на съобщението. Пуш услугата получаваше от нодата не текста на съобщението, а само сигнал за факта на неговото получаване. Затова потребителят виждаше известие "Получено ново съобщение". Четенето на него беше възможно само в месинджъра.
.
След това разбрахме, че в последната версия на известията от Apple има нови елементи за защита. Те UNNotificationServiceExtension, който позволява на разработчиците да изпращат напълно криптирани данни за известията чрез APNS. След това приложението на крайния потребител извършва декриптиране (или зарежда допълнителни данни) и показва известието. Тази идея взехме за основа на втората версия на пуш известията.
Сега разработихме втора версия на пуш известията за iOS, която позволява показването на текста на съобщението без риск за сигурността. В новата концепция логиката изглежда така:
- Пуш услугата изпраща пуш известие с номера на транзакцията (криптираното съобщение може да бъде много голямо, а размерът на известията е строго ограничен)
- Устройството при получаване на известието стартира нашето NotificationServiceExtension — микро приложение, което запитва от нодата транзакцията по id, декриптира с помощта на запазената парола и предоставя на системата ново известие. Паролата се съхранява в безопасно хранилище.
- Системата показва известие с декриптираното съобщение или превод.
- Ключовете не изчезват никъде, както и plaintext съобщението. Пуш услугата няма възможност да декриптира съобщението.
Тази версия приеха за работна и реализирахме в последното обновление на приложението за iOS.
Интересуващите се от техническата страна могат да се запознаят с изходния код: .
Източник: habr.com
