Sveiki, Habr!
Šiandien kalbėsiu apie tai, ką aš ir mano kolegos veikiame jau keletą mėnesių: tiesioginius pranešimus mobiliesiems momentiniams pasiuntiniams. Kaip jau sakiau, mūsų programoje pagrindinis dėmesys skiriamas saugumui. Todėl išsiaiškinome, ar tiesioginiuose pranešimuose yra „silpnųjų vietų“ ir, jei taip, kaip galime jas išlyginti, kad mūsų paslauga būtų įtraukta į šią naudingą parinktį.
Skelbiu mūsų vertimą su mažais priedais iš savęs. Jame pateikiami „tyrimo“ rezultatai ir pasakojimas apie tai, kaip problema buvo išspręsta.
Mes tiriame medžiagą
Klasikiniame modelyje tiesioginiai pranešimai daro pasiuntinius pažeidžiamus MITM (man-in-the-middle) atakoms. Pavyzdžiui, su Google, Microsoft ir senąja iMessage versija programa siunčia šifravimo raktus į Apple serverius – serveryje naudotojai autentifikuojami, o pranešimo antraštė (ar jos turinys) iššifruojama.
Dėl to yra galimybė perskaityti korespondenciją įgyjant prieigą prie tiesioginių pranešimų serverio. Tai reiškia, kad bet koks susirašinėjimo šifravimas yra nenaudingas: tiesioginiai pranešimai vis tiek paliks galimybę juos perskaityti trečiosioms šalims. Straipsnio autoriai šią galimybę aptarė plačiau. svetainėje Xaker.ru, skirta pranešimų šifravimo būdams.
Jei manote, kad „Apple“ ir „Google“ serveriai yra 100% apsaugoti nuo vartotojų šifravimo raktų nutekėjimo, atsižvelkite į tai, kad jų darbuotojai turi prieigą prie jų. O darbuotojai yra žmonės.
Nepaisant visų tiesioginių pranešimų pažeidžiamumo, daugelis „saugių“ momentinių pranešimų siuntėjų, įskaitant „Signalą“ ir „Telegram“, juos naudoja. Priešingu atveju vartotojai turės „rankiniu būdu“ stebėti naujus pranešimus nuolat prisijungdami prie programos. Tai labai nepatogu, o konkuruojantys pasiuntiniai gaus pranašumą.
Paranoja ir sveikas protas
Savo projekte prieš kelis mėnesius atidžiai ėmėmės šio klausimo. Kad būtume konkurencingi, turėjome pridėti tiesioginio pranešimo parinktį. Tačiau tuo pat metu neatidarykite saugumo spragų, nes bet koks duomenų nutekėjimas pakenks pasitikėjimui projektu.
Tačiau jau dabar turime svarbų pranašumą: mūsų messenger yra decentralizuotas (duomenys saugomi blokų grandinėje), o darbuotojai neturi prieigos prie paskyrų. Tik vartotojai turi šifravimo raktus, o viešieji pašnekovų raktai yra prieinami blokų grandinėje, kad apsaugotų nuo MITM atakų.
Pirmoje tiesioginių pranešimų versijoje nusprendėme kiek įmanoma saugiau ir iš viso neperduoti žinutės teksto. „Push“ paslauga iš mazgo negavo pranešimo teksto, o tik signalą apie jo gavimo faktą. Todėl vartotojas pamatė pranešimą „Gauta nauja žinutė“. Ją buvo galima perskaityti tik pasiuntinyje.
.
Po to sužinojome, kad naujausia „Apple“ pranešimų versija turi naujų saugos funkcijų. Jie UNNotificationServiceExtension, leidžiantis kūrėjams siųsti visiškai užšifruotus pranešimų duomenis per APNS. Tada galutinio vartotojo įrenginyje esanti programa atlieka iššifravimą (arba atsisiunčia papildomų duomenų) ir parodo pranešimą. Mes tai padarėme kaip antrosios tiesioginių pranešimų versijos pagrindą.
Dabar sukūrėme antrąją tiesioginių pranešimų versiją, skirtą iOS, kuri leidžia rodyti pranešimo tekstą be saugumo rizikos. Naujojoje koncepcijoje logika atrodo taip:
- „Push“ paslauga siunčia „push“ pranešimą su operacijos numeriu (šifruotas pranešimas gali būti labai didelis, o pranešimų dydis labai ribotas)
- Kai įrenginys gauna pranešimą, jis paleidžia mūsų NotificationServiceExtension – mikroprogramą, kuri prašo operacijos iš mazgo pagal ID, iššifruoja ją naudodama išsaugotą slaptafrazę ir siunčia sistemai naują pranešimą. Slaptafrazė saugoma saugioje saugykloje.
- Sistema rodo pranešimą su iššifruotu pranešimu arba vertimu.
- Raktai niekur nedingsta, kaip ir paprastas tekstinis pranešimas. Puslapio paslauga neturi galimybės iššifruoti pranešimo.
Priėmėme šią versiją kaip veikiančią ir įdiegėme ją naujausiame iOS programos atnaujinime.
Tie, kurie domisi technine puse, gali peržiūrėti šaltinio kodą: .
Šaltinis: www.habr.com