Pozdravljeni, Habr!
Danes bom govoril o tem, kar s kolegi počnemo že nekaj mesecev: potisna obvestila za mobilne takojšnje sporočanje. Kot sem že rekel, je v naši aplikaciji glavni poudarek na varnosti. Zato smo ugotovili, ali imajo potisna obvestila »šibke točke« in, če jih imajo, kako jih lahko izravnamo, da bi naši storitvi dodali to uporabno možnost.
Objavljam prevod našega z nekaj majhnimi dodatki od sebe. Vsebuje rezultate "preiskave" in zgodbo o tem, kako je bil problem rešen.
Pregledujemo material
V klasičnem modelu so zaradi potisnih obvestil sporočili ranljivi za napade MITM (človek v sredini). Na primer pri Googlu, Microsoftu in stari različici iMessage aplikacija pošilja šifrirne ključe Applovim strežnikom – na strežniku se uporabniki avtentikirajo in glava sporočila (ali njegova vsebina) dešifrira.
Posledično obstaja možnost branja korespondence z dostopom do strežnika za potisna obvestila. To pomeni, da je kakršno koli šifriranje korespondence neuporabno: potisna obvestila bodo še vedno pustila možnost, da jih preberejo tretje osebe. Avtorji članka so to možnost podrobneje obravnavali. na Xaker.ru, posvečen metodam šifriranja sporočil.
Če menite, da sta strežnika Apple in Google 100 % varna pred uhajanjem uporabniških šifrirnih ključev, upoštevajte dejstvo, da imajo njuni zaposleni dostop do njih. In zaposleni so ljudje.
Kljub vsem ranljivostim potisnih obvestil jih uporablja veliko »varnih« takojšnjih sporočil, vključno s Signalom in Telegramom. V nasprotnem primeru bodo morali uporabniki »ročno« spremljati nova sporočila s stalno prijavo v aplikacijo. Kar je zelo neprijetno in konkurenčni messengerji bodo imeli prednost.
Paranoja in zdrav razum
V našem projektu smo se tega vprašanja poglobljeno lotili že pred nekaj meseci. Da bi bili konkurenčni, smo morali dodati možnost potisnih obvestil. Toda hkrati ne odpirajte varnostne luknje, saj bo vsako uhajanje podatkov spodkopalo zaupanje v projekt.
Vendar že imamo pomembno prednost: naš messenger je decentraliziran (podatki so shranjeni v blockchainu), zaposleni nimajo dostopa do računov. Šifrirne ključe imajo le uporabniki, javni ključi sogovornikov pa so na voljo v blockchainu za zaščito pred napadi MITM.
Pri prvi različici potisnih obvestil smo se odločili, da bomo čim bolj varni in besedila sporočila sploh ne bomo posredovali. Potisna storitev ni prejela besedila sporočila iz vozlišča, temveč le signal o dejstvu njegovega prejema. Zato je uporabnik videl obvestilo »Prispelo je novo sporočilo«. Prebrati ga je bilo mogoče samo v messengerju.
.
Po tem smo izvedeli, da ima najnovejša Applova različica obvestil nove varnostne funkcije. Oni UNNotificationServiceExtension, ki razvijalcem omogoča pošiljanje popolnoma šifriranih obvestilnih podatkov prek APNS. Aplikacija na napravi končnega uporabnika nato izvede dešifriranje (ali prenese dodatne podatke) in prikaže obvestilo. Vzeli smo ga kot osnovo za drugo različico potisnih obvestil.
Zdaj smo razvili drugo različico potisnih obvestil za iOS, ki omogoča prikaz besedila sporočila brez varnostnega tveganja. V novem konceptu je logika videti takole:
- Potisna storitev pošlje potisno obvestilo s številko transakcije (šifrirano sporočilo je lahko zelo veliko, velikost obvestil pa je zelo omejena)
- Ko naprava prejme obvestilo, zažene našo NotificationServiceExtension – mikroaplikacijo, ki od vozlišča zahteva transakcijo po ID-ju, jo dešifrira s shranjenim geslom in sistemu pošlje novo obvestilo. Geslo je shranjeno v varni shrambi.
- Sistem prikaže obvestilo z dešifriranim sporočilom ali prevodom.
- Ključi ne gredo nikamor, tako kot navadno besedilno sporočilo. Potisna storitev ne more dešifrirati sporočila.
To različico smo sprejeli kot delujočo in jo implementirali v zadnjo posodobitev aplikacije iOS.
Kogar zanima tehnična stran, si lahko ogleda izvorno kodo: .
Vir: www.habr.com