Med andre ord sigter vi mod at yde sikkerhed, selv i tilfælde af et “værste tilfælde” serverbrud, hvor en allmægtig angriber har fuld kontrol over serverressourcer, for at inkludere muligheden for at læse og ændre back-end applikationskode og data og gå uopdaget i nogen tid.

tredjepart eksperter har løbende undersøgt vores ende-to-end kryptering og sikkerhed fra starten. Som en del af vores nyligt udgivne Kundesikkerhedsløfter validerede et førende uafhængigt sikkerhedsfirma, at meddelelsesindhold ikke kan læses på vores back-end-serverkomponenter. Dette papir undersøger spørgsmålet om sikkerhed og server kompromis mere bredt. Det opsummerer nøgleelementer i sikkerhed arkitektur, der giver modstandsdygtighed over for back-end server kompromis og diskuterer begivenheden i form af faktiske hacker kapaciteter, eller virkelige verden indvirkning.

mål for angriberen

for at forstå , hvad en angriber kan gøre med et kompromis med serveren, er vi nødt til at forstå serverens rolle i arkitekturen og overveje værdien af de data, der er indeholdt i backend-komponenter og databaser. Serveren spiller en central rolle i levering af meddelelser til støtte for både synkron og asynkron kommunikation. Det giver også centraliserede bruger mappe tjenester, tilladelse sæt, og profil og indstilling synkronisering.

angreb, der forsøger at udnytte serveren, kan generelt kategoriseres som følger:

• angreb rettet mod meddelelsessikkerhed eller adgang til indhold i almindelig tekst;
• angreb rettet mod information og metadata eller indsamling og våben af følsomme oplysninger om systemet eller dets brugere;
• angreb rettet mod tilgængelighed eller ødelæggelse af data.

vi diskuterer hver type angreb i de følgende afsnit.

Meddelelsessikkerhed

ved at kompromittere serveren får angriberen adgang til krypterede meddelelser såvel som offentlige kortvarige nøglepuljer . Meddelelserne krypteres dog ende-til-ende, og både de krypterede meddelelser og nøgler i nøglepuljerne godkendes ende-til-ende. Dette betyder, at angribere ikke har nogen evne til at læse eller ændre krypterede meddelelser, når de passerer gennem serveren, og de kan ikke manipulere nøglepuljerne til at udføre man in the middle-angreb.med disse beskyttelser på plads, skal angribere, der håber at få adgang til meddelelsesindhold, søge at tage kontrol over en god identitet. Identiteter er rodfæstet i asymmetriske nøglepar, der bruges til at signere og verificere data digitalt. Tillid etableres ved at verificere signaturkæden fra et givet objekt eller en kryptografisk komponent til rodidentiteten eller brugeren (f.eks.

for at producere en autentisk nøgle (eller meddelelse) skal en angriber gøre et af følgende:

1. Hent den private komponent i en brugers identitetsnøgle, som kan bruges til at godkende apps, der er logget ind på kontoen.

2. Hent den private komponent i en apps identitetsnøgle, som kan bruges til at producere autentiske kortvarige messaging-nøgler og godkende meddelelser sendt fra appen.

3. Narre en bruger til at acceptere en falsk identitetsnøgle for en målbruger, hvilket ville have den samme effekt som at få brugerens eksisterende identitetsnøgle.

de private komponenter i app identity keys er sikret i en krypteret klient-side datalager og uden for rækkevidde af en server-side hacker. De offentlige komponenter gemmes på serveren, men underskrives af brugerens (private) identitetsnøgle og beskytter dem mod manipulation. At narre brugere til at acceptere falske identitetsnøgler er mere et social engineering-angreb end teknisk angreb og har lidt at gøre med et fodfæste på serversiden . Derfor kommer serversidens angribers evne til at kompromittere en ægthedskilde — og virkelig deres eneste tekniske angrebsvej for at påvirke meddelelsessikkerhed — ned på deres evne til at kompromittere en brugers identitetsnøgle.

af forskellige årsager, der hovedsageligt er relateret til systemanvendelighed, gemmes brugeridentitetsnøgler på Uckr-serveren og sikres med stærk symmetrisk kryptering. Beskyttelse af disse data er i sidste ende en 256-bit nøgle, der er et stærkt kryptografisk derivat af brugerens adgangskode. Denne nøgle gemmes eller sendes aldrig til serveren, så en angriber, der forsøger at kompromittere en brugers identitetsnøgle, skal udføre et adgangskodegætningsangreb mod den lagrede version ved hjælp af en adgangskodederivatgenererende algoritme, der er specielt designet til at gøre processen så ressource og tidskrævende som muligt. For ikke-trivielle adgangskoder kunne vi forvente, at denne proces vil tage mange år til endda mange tusinder eller millioner af år, hvis brugeren simpelthen vælger en kvalitetsadgangskode på så lidt som 8 tegn i længden. For at kompromittere flere konti skal angriberen bruge den samme indsats igen og igen. Dette beskyttelsesniveau betyder, at angreb på serversiden mod brugeridentitetsnøgler er umulige mod alle undtagen de svageste konti. Se hvidbogen om adgangskodebeskyttelse.

Information og metadata

angriberen har adgang til alle oplysninger, som tjenesten har om sine brugere. Ved udformningen af denne trussel begrænser vi mængden af brugeroplysninger, vi gemmer, til det, der er minimalt nødvendigt for at levere service af høj kvalitet. Følgende er en liste over de brugerkontooplysninger, der er tilgængelige for :

:telefonnummer, hvis det leveres af netværksadministrator som en anden form for godkendelse

:Dato for oprettelse af en konto

netværksindstillinger, herunder begrænsede registreringer af nylige ændringer af netværksindstillinger (f. eks., aktivering eller deaktivering af Føderation)

ovenstående ville derfor være i fare for offentliggørelse i tilfælde af et serverkompromis. Vores retningslinjer for juridiske processer og fortrolighedspolitik indeholder mere detaljerede diskussioner om, hvordan vi begrænser indsamlingen og brugen af brugeroplysninger på vores platform.

kontrol af serveren giver også en angriber mulighed for at indsamle oplysninger og metadata, som tjenesten ignorerer. De to bedste eksempler på dette er klientens IP-adresser og meddelelsessporing.som en service er det helt uinteresseret i IP-adressen på klienterne. Vi optager dem ikke i standardkonfigurationsapplikationslogfiler eller gemmer dem i brugeroptegnelser. De er dog tilgængelige for visse komponenter i back-end-infrastrukturen, og forudsat at angriberen kontrollerer den rigtige komponent og udfører den rigtige trafik-og korrelationsanalyse, ville disse oplysninger være i fare.

er også uinteresseret i, hvem der kommunikerer med hvem på netværket. Vi registrerer ikke disse oplysninger i standardkonfigurationsapplikationslogfiler. Hvis man antager, at angriberen investerer en tilstrækkelig mængde tid og kræfter i processen, vil antallet, tiderne, typerne af meddelelser, der sendes og modtages, og kilde-og modtagerens id ‘ er Være i fare. Det er ikke muligt at foretage denne type analyse i Datalagrene, så denne type analyse ville være langt vanskeligere (men ikke umulig) at gøre i Me.

tilgængelighed

selvom det måske ikke er den mest interessante form for angreb, man kunne forestille sig mod en sikker messaging-tjeneste, har angreb, der er målrettet mod tilgængelighed af tjenester, meget reelle sandsynligheder og ret åbenlyse virkninger. Der er ikke meget at diskutere om dette emne i dette dokument andet end at anerkende risikoen, men en angriber med kontrol over ville have beføjelse til at deaktivere tjenester og slette data, hvad enten det blot skulle forårsage kaos eller nægte service til legitime brugere.

Resume

Vi håber, at dette papir var informativt for kunder, der ønsker at forstå den virkelige verdens indvirkning af et brud på serveren. Samlet set vil en sådan begivenhed, hvis den udnyttes af en dygtig modstander, potentielt sætte følgende i fare:

1. Sikkerheden ved fremtidige meddelelser om konti med svage adgangskoder.

2. Fortroligheden af begrænsede kontooplysninger og metadata.

3. Tilgængeligheden af tjenester.

Vælg kvalitetsadgangskoder.

Hvis der anvendes kvalitetsadgangskoder, kan et kompromis med serveren (kendt eller ukendt) betragtes som en hændelse med lav eller ingen effekt.

overvej periodisk rekeying.

periodisk oprettelse af et nyt nøglepar og Re-verificering med andre (f.eks. årligt, halvårligt) kan yderligere reducere risikoen for et vellykket adgangskodegætningsangreb for at kompromittere en brugers identitetsnøgle. Det er også en effektiv metode til rehabilitering af en brugerkonto, som du mener allerede er kompromitteret via adgangskodegættelse eller kompromis på klientsiden. Brugere kan genindtaste deres konto ved at udfylde ‘Glemt Adgangskode’ – strømmen i eller oprette et nyt ID i .