Hej Habr!
Idag ska jag prata om vad jag och mina kollegor har gjort i flera månader nu: push-meddelanden för mobila snabbmeddelanden. Som jag redan sa, i vår ansökan ligger huvudvikten på säkerhet. Därför tog vi reda på om push-meddelanden har "svaga punkter" och i så fall hur vi kan jämna ut dem för att lägga till detta användbara alternativ till vår tjänst.
Jag publicerar en översättning av vår med några små tillägg från mig själv. Den innehåller resultatet av "utredningen" och en berättelse om hur problemet löstes.
Vi undersöker materielen
I den klassiska modellen gör push-meddelanden budbärare sårbara för MITM-attacker (Man-in-the-middle). Till exempel med Google, Microsoft och den gamla versionen av iMessage skickar applikationen krypteringsnycklar till Apples servrar - på servern autentiseras användarna och meddelandehuvudet (eller dess innehåll) dekrypteras.
Som ett resultat finns det en chans att läsa korrespondensen genom att få tillgång till push-meddelandeservern. Detta innebär att all kryptering av korrespondens är värdelös: push-meddelanden lämnar fortfarande möjligheten att läsas av tredje part. Författarna till artikeln diskuterade denna möjlighet mer i detalj. på Xaker.ru, tillägnad metoder för att kryptera meddelanden.
Om du tror att Apples och Googles servrar är 100 % säkra mot läckande användarkrypteringsnycklar, överväg det faktum att deras anställda har tillgång till dem. Och anställda är människor.
Trots alla sårbarheter med push-meddelanden använder många "säkra" snabbmeddelanden, inklusive Signal och Telegram, dem. Annars måste användare "manuellt" övervaka nya meddelanden genom att ständigt logga in i applikationen. Vilket är väldigt obekvämt, och konkurrerande budbärare kommer att få en fördel.
Paranoia och sunt förnuft
I vårt projekt tog vi upp denna fråga noggrant för flera månader sedan. Vi behövde lägga till ett push-aviseringsalternativ för att vara konkurrenskraftiga. Men öppna samtidigt inte ett säkerhetshål, eftersom alla dataläckor kommer att undergräva förtroendet för projektet.
Vi har dock redan en viktig fördel: vår budbärare är decentraliserad (data lagras på blockkedjan), och anställda har inte tillgång till konton. Endast användare har krypteringsnycklar, och offentliga nycklar för samtalspartners är tillgängliga på blockchain för att skydda mot MITM-attacker.
I den första versionen av push-meddelanden bestämde vi oss för att spela det säkert så mycket som möjligt och inte överföra meddelandetexten alls. Push-tjänsten tog inte emot meddelandets text från noden, utan bara en signal om att det togs emot. Därför såg användaren meddelandet "Nytt meddelande har kommit". Det gick bara att läsa den i messenger.
.
Efter det fick vi veta att Apples senaste version av meddelanden har nya säkerhetsfunktioner. De UNNotificationServiceExtension, som tillåter utvecklare att skicka helt krypterad aviseringsdata över APNS. Appen på slutanvändarens enhet utför sedan dekrypteringen (eller laddar ner ytterligare data) och visar ett meddelande. Vi tog det som grund för den andra versionen av push-meddelanden.
Vi har nu utvecklat den andra versionen av push-notiser för iOS, som gör att du kan visa texten i meddelandet utan säkerhetsrisk. I det nya konceptet ser logiken ut så här:
- Push-tjänsten skickar ett push-meddelande med transaktionsnumret (det krypterade meddelandet kan vara mycket stort och storleken på aviseringarna är mycket begränsad)
- När enheten får ett meddelande startar den vår NotificationServiceExtension - en mikroapplikation som begär en transaktion från noden med id, dekrypterar den med den sparade lösenfrasen och skickar en ny notifikation till systemet. Lösenfrasen lagras i säker lagring.
- Systemet visar ett meddelande med ett dekrypterat meddelande eller översättning.
- Nycklarna går ingenstans, precis som vanligt textmeddelande. Push-tjänsten har inget sätt att dekryptera meddelandet.
Vi accepterade att den här versionen fungerade och implementerade den i den senaste uppdateringen av iOS-applikationen.
De som är intresserade av den tekniska sidan kan se källkoden: .
Källa: will.com