Hei Habr!
I dag skal jeg snakke om hva kollegene mine og jeg har gjort i flere måneder nå: push-varsler for mobile direktemeldinger. Som jeg allerede har sagt, i vår søknad er hovedvekten på sikkerhet. Derfor fant vi ut om push-varsler har "svake punkter" og i så fall hvordan vi kan utjevne dem for å legge til dette nyttige alternativet til tjenesten vår.
Jeg publiserer en oversettelse av vår med noen små tillegg fra meg selv. Den inneholder resultatene av "undersøkelsen" og en historie om hvordan problemet ble løst.
Vi undersøker materiellet
I den klassiske modellen gjør push-varsler budbringere sårbare for MITM-angrep (Man-in-the-middle). For eksempel, med Google, Microsoft og den gamle versjonen av iMessage, sender applikasjonen krypteringsnøkler til Apple-servere - på serveren blir brukere autentisert og meldingshodet (eller innholdet) dekryptert.
Som et resultat er det en sjanse til å lese korrespondansen ved å få tilgang til push-varslingsserveren. Dette betyr at all kryptering av korrespondanse er ubrukelig: push-varsler vil fortsatt gi mulighet for å bli lest av tredjeparter. Forfatterne av artikkelen diskuterte denne muligheten mer detaljert. på Xaker.ru, dedikert til metoder for å kryptere meldinger.
Hvis du tror Apple- og Google-servere er 100 % sikre mot lekkasje av brukerkrypteringsnøkler, bør du vurdere det faktum at deres ansatte har tilgang til dem. Og ansatte er mennesker.
Til tross for alle sårbarhetene til push-varsler, bruker mange "sikre" direktemeldinger, inkludert Signal og Telegram, dem. Ellers må brukere "manuelt" overvåke nye meldinger ved konstant å logge på applikasjonen. Noe som er veldig upraktisk, og konkurrerende budbringere vil få en fordel.
Paranoia og sunn fornuft
I vårt prosjekt tok vi denne problemstillingen nøye opp for flere måneder siden. Vi trengte å legge til et push-varslingsalternativ for å være konkurransedyktige. Men samtidig, ikke åpne et sikkerhetshull, fordi enhver datalekkasje vil undergrave tilliten til prosjektet.
Vi har imidlertid allerede en viktig fordel: vår messenger er desentralisert (data lagres på blokkjeden), og ansatte har ikke tilgang til kontoer. Bare brukere har krypteringsnøkler, og offentlige nøkler til samtalepartnere er tilgjengelige på blokkjeden for å beskytte mot MITM-angrep.
I den første versjonen av push-varslinger bestemte vi oss for å spille det trygt så mye som mulig og ikke overføre meldingsteksten i det hele tatt. Push-tjenesten mottok ikke teksten til meldingen fra noden, men bare et signal om mottakelsen. Derfor så brukeren "Ny melding har ankommet"-varselet. Det var mulig å lese det bare i messenger.
.
Etter det fikk vi vite at Apples nyeste versjon av varsler har nye sikkerhetsfunksjoner. De UNNotificationServiceExtension, som lar utviklere sende fullstendig krypterte varslingsdata over APNS. Appen på sluttbrukerens enhet utfører deretter dekrypteringen (eller laster ned tilleggsdata) og viser et varsel. Vi tok det som grunnlag for den andre versjonen av push-varslinger.
Vi har nå utviklet den andre versjonen av push-varsler for iOS, som lar deg vise teksten i meldingen uten sikkerhetsrisiko. I det nye konseptet ser logikken slik ut:
- Push-tjenesten sender en push-melding med transaksjonsnummeret (den krypterte meldingen kan være veldig stor, og størrelsen på varslene er svært begrenset)
- Når enheten mottar et varsel, starter den vår NotificationServiceExtension - en mikroapplikasjon som ber om en transaksjon fra noden etter id, dekrypterer den ved å bruke den lagrede passordfrasen og sender et nytt varsel til systemet. Passordet lagres på sikker lagring.
- Systemet viser et varsel med en dekryptert melding eller oversettelse.
- Nøklene går ingen steder, akkurat som en ren tekstmelding. Push-tjenesten har ingen måte å dekryptere meldingen på.
Vi godtok denne versjonen som fungerende og implementerte den i den siste oppdateringen av iOS-applikasjonen.
De som er interessert i den tekniske siden kan se kildekoden: .
Kilde: www.habr.com