Hello, Habr!
I dag vil jeg fortælle om, hvad vi har arbejdet på med kollegerne i flere måneder: push-notifikationer til mobile messengers. Som jeg allerede har nævnt, er der stort fokus på sikkerhed i vores app. Derfor har vi undersøgt, om push-notifikationer har "svage punkter", og hvis ja, hvordan vi kan afbøde dem for at tilføje denne nyttige funktion til vores service.
Jeg offentliggør oversættelsen af vores med nogle små tilføjelser fra min side. Den indeholder resultaterne af vores "undersøgelse" og en fortælling om, hvordan vi løste problemet.
Vi undersøger materien
I den klassiske model gør push-notifikationer messengers sårbare over for MITM-angreb (Man-in-the-middle). For eksempel sender Google, Microsoft og den gamle version af iMessage krypteringsnøgler til servere hos Apple — autentificeringen af brugerne og afkrypteringen af beskedens overskrift (eller indholdet) foregår på serveren.
Som et resultat er der en risiko for at læse samtalen ved at få adgang til push-notifikationsserveren. Det betyder, at enhver kryptering af samtalen er nytteløs: push-notifikationer vil stadig gøre det muligt for tredjeparter at læse den. Denne mulighed blev diskuteret nærmere af forfatterne til artiklen på Xaker.ru, som handler om metoder til at kryptere beskeder.
Hvis du mener, at servere hos Apple og Google 100% ikke vil tillade lækage af brugernes krypteringsnøgler, så tænk på, at deres medarbejdere har adgang til dem. Og medarbejdere er mennesker.
På trods af alle sårbarhederne i push-notifikationer anvender mange "sikre" messengers, herunder Signal og Telegram, dem. Ellers ville brugerne skulle "manuelt" overvåge nye beskeder ved konstant at tjekke appen, hvilket er temmelig besværligt, og konkurrentmessengers ville få en fordel.
Paranoia og sund fornuft
I vores projekt har vi arbejdet intensivt med dette spørgsmål i flere måneder. Vi skulle skabe en funktion til push-notifikationer for at være konkurrencedygtige. Men vi ønsker ikke at lave en sikkerhedssvaghed, for enhver datalækage vil underminerer tilliden til projektet.
Dog har vi allerede en vigtig fordel: vores messenger er decentraliseret (data opbevares i blockchain), og medarbejdere har ikke adgang til konti. Krypteringsnøglerne er kun hos brugerne, mens de offentlige nøgler til samtalepartnere er tilgængelige i blockchain for at beskytte mod MITM-angreb.
I den første version af push-notifikationerne besluttede vi at være ekstra forsigtige og ikke overføre teksten i beskeden overhovedet. Push-tjenesten modtog ikke tekstbmessage fra noden, men kun et signal om, at en besked var modtaget. Derfor så brugeren meddelelsen 'Der er ankommet en ny besked'. Den kunne kun læses i messenger-appen.
.
Efter dette fandt vi ud af, at der i den seneste version af notifikationer fra Apple er nye sikkerhedselementer. De UNNotificationServiceExtension, som gør det muligt for udviklere at sende fuldt krypterede data vedrørende notifikationer via APNS. Derefter udfører applikationen på slutbrugerens enhed dekryptering (eller henter yderligere data) og viser notifikationen. Det var denne metode, vi tog udgangspunkt i for den anden version af push-notifikationerne.
Vi har nu udviklet den anden version af push-notifikationer til iOS, som muliggør visning af tekstbeskeder uden sikkerhedstrusler. I det nye koncept ser logikken således ud:
- Push-tjenesten sender en push-notifikation med transaktionsnummeret (krypterede beskeder kan være meget store, mens størrelsen på notifikationer er stærkt begrænset)
- Enheden starter vores NotificationServiceExtension ved modtagelsen af notifikationen - en mikroapp, der anmoder noden om transaktionen via id, dekrypterer med den gemte adgangsfrase og returnerer et nyt notifikationssystem. Adgangsfrasen opbevares i en sikker opbevaring.
- Systemet viser notifikationen med den dekrypterede besked eller oversættelse.
- Nøglerne går ingen steder, ligesom den ukrypterede besked. Push-tjenesten har ikke mulighed for at dekryptere beskeden.
Denne version har vi accepteret som operationel og implementeret i den seneste opdatering af appen til iOS.
De, der er interesseret i den tekniske side af sagen, kan se koden: .
Kilde: habr.com
