externe experts hebben onze end-to-end encryptie en beveiliging vanaf het begin continu doorgelicht. Als onderdeel van onze onlangs vrijgegeven customer Security Beloften, heeft een toonaangevend onafhankelijk beveiligingsbedrijf gevalideerd dat de inhoud van berichten niet leesbaar is op onze back-end server componenten. In dit document wordt de kwestie van beveiliging en server compromis breder onderzocht. Het vat de belangrijkste elementen van Wickr ‘ s security architectuur die veerkracht bieden aan back-end server compromis en bespreekt de gebeurtenis in termen van werkelijke aanvaller mogelijkheden, of real-world impact.

doelen van de aanvaller

om te begrijpen wat een aanvaller kan doen met een Wickr server compromis , moeten we de rol van de server in Wickr architectuur begrijpen en rekening houden met de waarde van de gegevens in back-end componenten en databases. De Wickr-server speelt een sleutelrol in de berichtenlevering ter ondersteuning van zowel synchrone als asynchrone communicatie. Het biedt ook gecentraliseerde user directory services, machtigingssets, en profiel en instelling synchronisatie.

aanvallen die de Wickr-server proberen te exploiteren kunnen over het algemeen als volgt worden gecategoriseerd:

• aanvallen gericht op berichtbeveiliging of toegang tot inhoud van berichten in platte tekst;
• aanvallen gericht op informatie en metagegevens, of het verzamelen en wapenen van gevoelige informatie over het systeem of zijn gebruikers;
• aanvallen gericht op beschikbaarheid of vernietiging van gegevens.

we bespreken elk type aanval in de secties die volgen.

Berichtbeveiliging

door de server in gevaar te brengen, krijgt de aanvaller toegang tot versleutelde berichten en tot publieke kortstondige sleutelgroepen . De berichten worden echter end-to-end versleuteld en zowel de versleutelde berichten als de sleutels in de sleutelpools worden end-to-end geverifieerd. Dit betekent dat aanvallers geen mogelijkheid hebben om versleutelde berichten te lezen of te wijzigen als ze door de server gaan en ze kunnen de belangrijkste pools niet manipuleren om man in the middle aanvallen uit te voeren.

met deze beveiligingen op hun plaats, moeten aanvallers die toegang willen krijgen tot berichtinhoud proberen de controle over een Wickr-identiteit over te nemen. Wickr identiteiten zijn geworteld in asymmetrische sleutelparen die worden gebruikt om gegevens digitaal te ondertekenen en te verifiëren. Vertrouwen wordt tot stand gebracht door het verifiëren van de handtekeningketen van een bepaald object of cryptografische component naar de root-identiteit of gebruiker (bijvoorbeeld bericht naar app, app naar gebruiker).

om een authentieke sleutel (of bericht) te produceren, moet een aanvaller een van de volgende handelingen verrichten:

1. Verkrijg de private component van de identiteitssleutel van een gebruiker, die kan worden gebruikt om Wickr-apps die zijn aangemeld bij het account te verifiëren.

2. Verkrijg de private component van de identiteitssleutel van een app, die kan worden gebruikt om authentieke kortstondige berichtensleutels te produceren en berichten die vanuit de app worden verzonden te authenticeren.

3. Een gebruiker verleiden tot het accepteren van een valse identiteitssleutel voor een doelgebruiker, wat hetzelfde effect zou hebben als het verkrijgen van de bestaande identiteitssleutel van de gebruiker.

de private componenten van app identity keys zijn beveiligd in een versleutelde client-side data store en buiten het bereik van een server-side aanvaller. De openbare componenten worden opgeslagen op de server, maar zijn ondertekend door de (privé) identiteitssleutel van de gebruiker, waardoor ze worden beschermd tegen manipulatie. Tricking gebruikers in het accepteren van valse identiteit sleutels is meer van een social engineering aanval dan technische aanval en heeft weinig te maken met een server-side voet aan de grond . Daarom is het vermogen van de server-side aanvaller om een bron van authenticiteit in gevaar te brengen — en echt hun enige technische manier van aanval om de beveiliging van berichten te beïnvloeden — komt neer op hun vermogen om de identiteitssleutel van een gebruiker in gevaar te brengen.

om verschillende redenen die voornamelijk te maken hebben met de gebruiksvriendelijkheid van het systeem, worden gebruikersidentiteitssleutels opgeslagen op de Wickr-server en beveiligd met sterke symmetrische versleuteling. Het beschermen van deze gegevens is uiteindelijk een 256-bit sleutel die een sterke cryptografische afgeleide van het wachtwoord van de gebruiker is. Deze sleutel wordt nooit opgeslagen of naar de server verzonden, dus een aanvaller die probeert de identiteitssleutel van een gebruiker in gevaar te brengen, moet een aanval op de opgeslagen versie uitvoeren met behulp van een algoritme voor het genereren van wachtwoorden dat speciaal is ontworpen om het proces zo bron-en tijdrovend mogelijk te maken. Voor niet-triviale wachtwoorden, we kunnen verwachten dat dit proces vele jaren tot zelfs vele duizenden of miljoenen jaren duren als de gebruiker gewoon kiest voor een kwaliteit wachtwoord van slechts 8 tekens in lengte. Om meerdere accounts in gevaar te brengen, zou de aanvaller dezelfde inspanning opnieuw en opnieuw moeten besteden. Dit niveau van bescherming betekent server-side aanvallen op gebruiker identity keys zijn onhaalbaar tegen alle, behalve de zwakste accounts. Zie Wickr ‘ s White Paper over wachtwoordbeveiliging.

informatie en metadata

met controle over de Wickr-server heeft de aanvaller toegang tot alle informatie die de service over zijn gebruikers heeft. Bij het ontwerpen voor deze bedreiging beperkt Wickr de hoeveelheid gebruikersinformatie die we opslaan tot wat minimaal nodig is om kwaliteit van de dienstverlening te bieden. Het volgende is een lijst van de user account informatie beschikbaar te Wickr diensten op het moment van dit schrijven:

Wickr Mij:

• Datum een account was aangemaakt
• Type van apparaat(en) waarop de rekening werd gebruikt (bijvoorbeeld, iOS, Android)
• Datum van de laatste gebruik
• Totaal aantal verzonden/ontvangen berichten
• Aantal externe-ID ’s (telefoonnummers) die is verbonden met de account (niet de klare externe-Id’ s zelf)
• Beperkte verslagen van recente wijzigingen in de account-instellingen (bijvoorbeeld, het toevoegen of verwijderen van een apparaat; bevat geen berichtinhoud of routing-en afleverinformatie)
• Wickr versienummer

Wickr Pro:

• Wickr Pro-ID (e-mailadres)
• Netwerk aansluiting
• telefoonnummer, indien verstrekt door een netwerkbeheerder als een tweede vorm van authenticatie
• Datum een account was aangemaakt
• Type van apparaat(en) op die account gebruikt is
• Datum van de laatste gebruik
• Totaal aantal verzonden/ontvangen berichten
• Aantal externe-ID ’s (telefoonnummers) die is verbonden met de account (niet de klare externe-Id’ s zelf)
• Beperkte verslagen van recente wijzigingen in de account-instellingen (bijvoorbeeld, het toevoegen of verwijderen van een apparaat; bevat geen berichtinhoud of routing-en afleverinformatie)
• Wickr versienummer
• betalingsgerelateerde informatie
• netwerkinstellingen inclusief beperkte records van recente wijzigingen in netwerkinstellingen (bijv. federation in-of uitschakelen)

Wickr Enterprise (customer-controlled deployment):

• Wickr Enterprise ID (handle)
• netwerkaansluiting
• datum waarop een account is aangemaakt
• type apparaat(en) waarop een account is gebruikt
• Datum van het laatste gebruik
• totaal aantal verzonden/ontvangen berichten
• beperkte records van recente wijzigingen in Accountinstellingen (bijvoorbeeld het toevoegen of verwijderen van een apparaat; bevat geen berichtinhoud of Routering en afleverinformatie)
• Wickr versienummer
• netwerkinstellingen inclusief beperkte records van recente wijzigingen in netwerkinstellingen (bijv. federation in-of uitschakelen)

het bovenstaande zou daarom het risico van openbaarmaking in het geval van een server compromis. Onze richtlijnen voor juridische processen en Privacybeleid bevatten meer gedetailleerde discussies over hoe we het verzamelen en gebruiken van gebruikersinformatie op ons platform beperken.

controle over de server biedt een aanvaller ook de mogelijkheid om informatie en metadata te verzamelen die de service negeert. De twee beste voorbeelden hiervan in Wickr zijn client IP-adressen en message tracking.

Wickr as a service is totaal niet geïnteresseerd in het IP-adres van Wickr-clients. We registreren ze niet in standaard configuratietoepaslogboeken of slaan ze niet op in gebruikersrecords. Ze zijn echter beschikbaar voor bepaalde onderdelen van de back-end-infrastructuur, en ervan uitgaande dat de aanvaller de juiste component controleert en de juiste verkeers-en correlatieanalyse uitvoert, zou deze informatie in gevaar zijn.

Wickr is ook niet geïnteresseerd in wie met wie communiceert op het netwerk. We slaan deze informatie niet op in standaard configuratietoepaslogboeken. Echter, ervan uitgaande dat de aanvaller investeert een voldoende hoeveelheid tijd en moeite in het proces, het aantal, tijden, soorten berichten verzonden en ontvangen, en bron en ontvanger Wickr ID ‘ s zou in gevaar. Plaintext Wickr ID ‘ s zijn niet beschikbaar in Wickr Me data stores, dus dit soort analyse zou veel moeilijker (maar niet onmogelijk) te doen in Wickr Me.

beschikbaarheid

hoewel het misschien niet de meest interessante vorm van aanval is die men zich kan voorstellen tegen een beveiligde berichtendienst, hebben aanvallen die gericht zijn op de beschikbaarheid van diensten zeer reële waarschijnlijkheid en tamelijk duidelijke gevolgen. Er is niet veel te bespreken over dit onderwerp in dit document anders dan om het risico te erkennen, maar een aanvaller met controle over Wickr servers zou de macht om diensten uit te schakelen en gegevens te verwijderen, of gewoon chaos veroorzaken of weigeren service aan legitieme gebruikers.

samenvatting

We hopen dat dit artikel informatief was voor klanten die de werkelijke impact van een Wickr-serverbreuk willen begrijpen. In totaal zou een dergelijke gebeurtenis, indien uitgebuit door een geschikte tegenstander, mogelijk het volgende in gevaar brengen:

1. De beveiliging van toekomstige berichten van accounts met zwakke wachtwoorden.

2. De vertrouwelijkheid van beperkte accountinformatie en metagegevens.

3. De beschikbaarheid van diensten.

kies kwaliteitswachtwoorden.

als kwaliteitswachtwoorden worden gebruikt, kan een Wickr-servercompromis (bekend of onbekend) worden beschouwd als een lage of geen impact gebeurtenis.

overweeg periodieke herijking.

het periodiek aanmaken van een nieuw sleutelpaar en het opnieuw verifiëren met anderen (bijvoorbeeld jaarlijks, halfjaarlijks) kan het risico van een succesvolle aanval op het Raden van wachtwoorden verder verminderen om de identiteitssleutel van een gebruiker in gevaar te brengen. Het is ook een effectieve methode voor het rehabiliteren van een gebruikersaccount waarvan u denkt dat is al gecompromitteerd via wachtwoord raden of client-side compromis. Gebruikers kunnen hun account opnieuw aanmaken door het invullen van de’ Wachtwoord vergeten ‘ stroom in Wickr Pro en Wickr Enterprise of het creëren van een nieuwe ID in Wickr Me.