Bok, Habr!
Danas ću govoriti o tome čime se mi i moji kolege bavimo već nekoliko mjeseci: o push obavijestima za mobilne messenger aplikacije. Kao što sam već spomenuo, fokus našeg aplikacije je na sigurnosti. Stoga smo istraživali postoje li "slabe tačke" u push obavijestima i ako postoje, kako ih možemo neutralizirati kako bismo dodali ovu korisnu opciju našoj usluzi.
Objavljujem prijevod našeg s malim dodacima s moje strane. U njemu su sažeci "istrage" i priča o tome kako smo riješili problem.
Istražujemo materiju
U klasičnom modelu push obavijesti čine messengere ranjivima na MITM napade (Man-in-the-middle, "Čovjek posredniku"). Na primjer, kod Googlea, Microsofta i u staroj verziji iMessage aplikacija šalje ključeve šifriranja na Appleove poslužitelje — autentifikacija korisnika i dešifriranje zaglavlja poruke (ili njenog sadržaja) odvija se na poslužitelju.
Na kraju, postoji šansa da se pročita prepiska ako se dobije pristup poslužitelju push obavijesti. To znači da su svi oblici šifriranja prepiske beskorisni: push obavijesti će i dalje ostaviti mogućnost za čitanje od strane trećih lica. Detaljnije su ovu mogućnost raspravljali autori članka na Xaker.ru, koji se posvetio metodama šifriranja poruka.
Ako mislite da poslužitelji Applea i Googlea 100% neće dopustiti curenje ključeva šifriranja korisnika, razmislite o tome da im pristup imaju njihovi zaposlenici. A zaposlenici su ljudi.
Uprkos svim ranjivostima push obavijesti, mnogi "sigurni" messengeri, uključujući Signal i Telegram, ih koriste. Jer u suprotnom, korisnici bi morali "ručno" nadzirati nove poruke stalno se prijavljujući u aplikaciju. Što je prilično nezgodno, a konkurentni messengeri bi dobili prednost.
Paranoja i zdravi razum
U našem projektu, mi smo se ozbiljno bavili ovim pitanjem prije nekoliko mjeseci. Trebali smo stvoriti opciju push obavijesti kako bismo bili konkurentni. No, pritom ne želimo otvoriti rupu u sigurnosti, jer bi bilo koje curenje podataka moglo potkopati povjerenje u projekt.
Ipak, već imamo važnu prednost: naš messenger je decentraliziran (podaci se pohranjuju u blockchainu), a zaposlenici nemaju pristup korisničkim računima. Ključevi šifriranja su samo kod korisnika, a javni ključevi sugovornika dostupni su u blockchainu, kako bi se zaštitili od MITM napada.
U prvoj verziji push notifikacija odlučili smo maksimalno se zaštititi i uopće nismo prenosili tekst poruke. Push servis je od čvora primao samo signal o samom prijemu, a ne tekst poruke. Zato je korisnik mogao vidjeti obavijest 'Stigla je nova poruka'. Pročitati ju je bilo moguće samo u messengeru.
.
Nakon toga saznali smo da u posljednjoj verziji obavijesti od Applea postoje novi zaštitni elementi. Oni UNNotificationServiceExtension, koji omogućava programerima da šalju potpuno šifrirane podatke obavijesti preko APNS. Potom aplikacija na uređaju krajnjeg korisnika dešifrira (ili učitava dodatne podatke) i prikazuje obavijest. Nju smo uzeli kao osnovu za drugu verziju push notifikacija.
Sada smo razvili drugu verziju push obavijesti za iOS, koja omogućava prikazivanje teksta poruke bez ugrožavanja sigurnosti. U novoj konceptu logika izgleda ovako:
- Push servis šalje push obavijest s brojem transakcije (šifrirana poruka može biti vrlo velika, a veličina obavijesti je jako ograničena)
- Uređaj prilikom primanja obavijesti pokreće naš NotificationServiceExtension — mikroaplikaciju koja traži od čvora transakciju po id-u, dešifrira uz pomoć pohranjene lozinke i predaje sustavu novu obavijest. Lozinka se pohranjuje u sigurnom skladištu.
- Sustav prikazuje obavijest s dešifriranom porukom ili prijevodom.
- Ključevi ne odlaze nikamo, kao ni plain text poruka. Push servis nema mogućnost dešifriranja poruke.
Ovu verziju smo prihvatili kao funkcionalnu i implementirali u posljednjem ažuriranju aplikacije za iOS.
Zainteresirani za tehničku stranu mogu pogledati izvorni kod: .
Izvor: habr.com
