Прывітанне, Хабр!
Сёння раскажу пра тое, чым мы з калегамі занятыя ўжо некалькі месяцаў: пра пуш-паведамленні для мабільных месэнджараў. Як я ўжо казаў, у нашым дадатку галоўны ўпор зроблены на бяспеку. Таму мы высвятлялі, ці ёсць у пуш-паведамленняў "слабыя месцы" і калі так, то як мы можам іх нівеліраваць, каб дадаць гэтую карысную опцыю ў наш сэрвіс.
Публікую пераклад нашай з невялікімі даданнямі ад сябе. У ёй вынікі "расследавання" і аповяд аб тым, як вырашылі праблему.
Даследуем матчнасць
У класічнай мадэлі пуш-паведамлення робяць месэнджэры ўразлівымі для нападаў 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