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