Привіт, Хабре!
Сьогодні розповім про те, чим ми з колегами зайняті вже кілька місяців: про пуш-повідомлення для мобільних месенджерів. Як я вже казав, у нашому додатку головний акцент зроблено на безпеку. Тому ми з'ясовували, чи є у пуш-повідомлень слабкі місця і якщо так, то як ми можемо їх нівелювати, щоб додати цю корисну опцію в наш сервіс.
Публікую переклад нашої з невеликими додаваннями від себе. У ній підсумки "розслідування" та розповідь про те, як вирішили проблему.
Досліджуємо матчність
У класичній моделі пуш-повідомлення роблять месенджери вразливими для атак MITM (Man-in-the-middle, "Людина посередині"). Наприклад, у Google, Microsoft і в старій версії iMessage програма відправляє ключі шифрування на сервери Apple - на сервері відбувається автентифікація користувачів та дешифрування заголовка повідомлення (або його змісту).
У результаті є шанс прочитати листування, отримавши доступ до сервера пуш-повідомлень. А це означає, що будь-які шифрування листування марні: пуш-повідомлення все одно залишать можливість для читання третіми особами. Докладніше цю можливість обговорювали автори статті на Xaker.ru, присвяченій методам шифрування повідомлень.
Якщо вам здається, що сервери Apple та Google 100% не допустять витоку ключів шифрування користувачів, подумайте про те, що до них мають доступ їхні співробітники. А співробітники – люди.
При всіх уразливості пухів, багато «безпечних» месенджерів, включаючи Signal і Telegram, використовують їх. Адже інакше користувачам доведеться «вручну» моніторити нові повідомлення, постійно заходячи до додатку. Що дуже незручно, і месенджери-конкуренти матимуть перевагу.
Параноя та здоровий глузд
У нашому проекті ми зайнялися цим питанням кілька місяців тому. Нам потрібно було зробити опцію пуш-повідомлень, щоби бути конкурентоспроможними. Але при цьому не прокрутити дірку в безпеці, тому що будь-який витік даних підірве довіру до проекту.
Втім, ми вже маємо важливу перевагу: наш месенджер децентралізований (дані зберігаються в блокчейні), при цьому співробітники не мають доступу до облікових записів. Ключі шифрування є лише у користувачів, а публічні ключі співрозмовників доступні у блокчейні, щоб захистити від MITM-атак.
У першій версії пушкою ми вирішили максимально перестрахуватись і взагалі не передавати текст повідомлення. Пуш-сервіс отримував від ноди не текст повідомлення, лише сигнал про факт його отримання. Тому користувач бачив повідомлення "Прийшло нове повідомлення". Прочитати його було можливо лише у месенджері.
.
Після цього ми дізналися, що в останній версії повідомлень від Apple є нові елементи захисту. Вони UNNotificationServiceExtension, який дозволяє розробникам надсилати повністю зашифровані дані повідомлень через APNS. Потім програма кінцевого користувача виконує розшифровку (або завантажує додаткові дані) і відображає повідомлення. Її ми взяли за основу другої версії пушком.
Наразі ми розробили другу версію пуш-повідомлень для iOS, яка дозволяє відображати текст повідомлення без загрози безпеці. У новій концепції логіка має такий вигляд:
- Пуш сервіс відправляє push-повідомлення з номером транзакції (шифроване повідомлення може бути дуже великим, а розмір повідомлень дуже обмежений)
- Пристрій при отриманні повідомлення запускає наш NotificationServiceExtension - мікрододаток, який запитує у ноди транзакцію по id, розшифровує за допомогою збереженої пасфрази, і віддає системі нове повідомлення. Пасфраза зберігається у безпечному сховищі.
- Система показує повідомлення із розшифрованим повідомленням або перекладом.
- Ключі нікуди не йдуть, як і plain text-повідомлення. Пуш-сервіс немає можливості розшифрувати повідомлення.
Цю версію ми прийняли за робочу та реалізували в останньому оновленні програми для iOS.
Ті, хто цікавиться технічною стороною, можуть подивитися вихідний код: .
Джерело: habr.com