Hej Habr!
I dag vil jeg tale om, hvad mine kolleger og jeg har lavet i flere måneder nu: push-meddelelser til mobile instant messengers. Som jeg allerede har sagt, i vores ansøgning er hovedvægten lagt på sikkerhed. Derfor fandt vi ud af, om push-meddelelser har "svage punkter", og i så fald, hvordan vi kan udjævne dem for at tilføje denne nyttige mulighed til vores tjeneste.
Jeg udgiver en oversættelse af vores med nogle små tilføjelser fra mig selv. Den indeholder resultaterne af "undersøgelsen" og en historie om, hvordan problemet blev løst.
Vi undersøger materialet
I den klassiske model gør push-meddelelser budbringere sårbare over for MITM-angreb (Man-in-the-middle). For eksempel med Google, Microsoft og den gamle version af iMessage sender applikationen krypteringsnøgler til Apple-servere - på serveren bliver brugerne autentificeret, og meddelelseshovedet (eller dets indhold) dekrypteres.
Som et resultat er der en chance for at læse korrespondancen ved at få adgang til push-notifikationsserveren. Det betyder, at enhver kryptering af korrespondance er ubrugelig: push-meddelelser vil stadig give mulighed for at blive læst af tredjeparter. Artiklens forfattere diskuterede denne mulighed mere detaljeret. på Xaker.ru, dedikeret til metoder til kryptering af meddelelser.
Hvis du mener, at Apple og Googles servere er 100 % sikre mod lække brugerkrypteringsnøgler, så overvej det faktum, at deres medarbejdere har adgang til dem. Og medarbejdere er mennesker.
På trods af alle sårbarhederne ved push-meddelelser, bruger mange "sikre" instant messengers, inklusive Signal og Telegram, dem. Ellers bliver brugere nødt til at "manuelt" overvåge nye meddelelser ved konstant at logge på applikationen. Hvilket er meget ubelejligt, og konkurrerende budbringere vil få en fordel.
Paranoia og sund fornuft
I vores projekt tog vi dette spørgsmål nøje op for flere måneder siden. Vi var nødt til at tilføje en push-meddelelsesmulighed for at være konkurrencedygtige. Men samtidig må du ikke åbne et sikkerhedshul, for ethvert datalæk vil underminere tilliden til projektet.
Vi har dog allerede en vigtig fordel: Vores messenger er decentral (data gemmes på blockchain), og medarbejderne har ikke adgang til konti. Kun brugere har krypteringsnøgler, og offentlige nøgler til samtalepartnere er tilgængelige på blockchain for at beskytte mod MITM-angreb.
I den første version af push-meddelelser besluttede vi at spille det sikkert så meget som muligt og slet ikke sende beskedteksten. Push-tjenesten modtog ikke teksten til beskeden fra noden, men kun et signal om, at den blev modtaget. Derfor så brugeren meddelelsen "Ny besked er ankommet". Det var kun muligt at læse det i messenger.
.
Derefter lærte vi, at Apples seneste version af notifikationer har nye sikkerhedsfunktioner. De UNNotificationServiceExtension, som giver udviklere mulighed for at sende fuldt krypterede notifikationsdata over APNS. Appen på slutbrugerens enhed udfører derefter dekrypteringen (eller downloader yderligere data) og viser en meddelelse. Vi tog det som grundlag for den anden version af push-meddelelser.
Vi har nu udviklet den anden version af push-beskeder til iOS, som giver dig mulighed for at vise teksten i beskeden uden en sikkerhedsrisiko. I det nye koncept ser logikken således ud:
- Push-tjenesten sender en push-meddelelse med transaktionsnummeret (den krypterede meddelelse kan være meget stor, og størrelsen af meddelelser er meget begrænset)
- Når enheden modtager en notifikation, starter den vores NotificationServiceExtension - en mikroapplikation, der anmoder om en transaktion fra noden efter id, dekrypterer den ved hjælp af den gemte adgangssætning og sender en ny notifikation til systemet. Adgangssætningen er gemt i sikker opbevaring.
- Systemet viser en meddelelse med en dekrypteret besked eller oversættelse.
- Tasterne går ingen steder, ligesom den almindelige tekstbesked. Push-tjenesten har ingen måde at dekryptere beskeden på.
Vi accepterede denne version som fungerende og implementerede den i den seneste opdatering af iOS-applikationen.
Interesserede i den tekniske side kan se kildekoden: .
Kilde: www.habr.com