nsere Experten haben unsere End-to-End-Verschlüsselung und Sicherheit von Anfang an kontinuierlich überprüft. Im Rahmen unserer kürzlich veröffentlichten Customer Security Promises hat eine führende unabhängige Sicherheitsfirma bestätigt, dass Nachrichteninhalte auf unseren Back-End-Serverkomponenten nicht lesbar sind. Dieses Papier untersucht das Thema Sicherheit und Serverkompromisse weiter gefasst. Es fasst Schlüsselelemente der Sicherheitsarchitektur von Wickr zusammen, die Widerstandsfähigkeit gegen Back-End-Server-Kompromisse bieten, und diskutiert das Ereignis in Bezug auf tatsächliche Angreiferfähigkeiten oder reale Auswirkungen.

Ziele des Angreifers

Um zu verstehen, was ein Angreifer mit einem Wickr-Server-Kompromiss tun kann, müssen wir die Rolle des Servers in der Wickr-Architektur verstehen und den Wert der in Back-End-Komponenten und Datenbanken enthaltenen Daten berücksichtigen. Der Wickr-Server spielt eine Schlüsselrolle bei der Nachrichtenübermittlung zur Unterstützung der synchronen und asynchronen Kommunikation. Es bietet auch zentralisierte Benutzerverzeichnisdienste, Berechtigungssätze sowie die Synchronisierung von Profilen und Einstellungen.

Angriffe, die versuchen, den Wickr-Server auszunutzen, können im Allgemeinen wie folgt kategorisiert werden:

• Angriffe auf die Nachrichtensicherheit oder den Zugriff auf Klartext-Nachrichteninhalte;
• Angriffe auf Informationen und Metadaten oder das Sammeln und Bewaffnen sensibler Informationen über das System oder seine Benutzer;
• Angriffe auf die Verfügbarkeit oder die Zerstörung von Daten.

Wir diskutieren jede Art von Angriff in den folgenden Abschnitten.

Nachrichtensicherheit

Durch die Kompromittierung des Servers erhält der Angreifer Zugriff auf verschlüsselte Nachrichten sowie öffentliche ephemere Schlüsselpools . Die Nachrichten werden jedoch Ende-zu-Ende verschlüsselt, und sowohl die verschlüsselten Nachrichten als auch die Schlüssel in den Schlüsselpools werden Ende-zu-Ende authentifiziert. Dies bedeutet, dass Angreifer nicht in der Lage sind, verschlüsselte Nachrichten zu lesen oder zu ändern, während sie den Server passieren, und sie können die Schlüsselpools nicht manipulieren, um Man-in-the-Middle-Angriffe auszuführen.

Mit diesen Schutzmaßnahmen müssen Angreifer, die Zugriff auf Nachrichteninhalte erhalten möchten, versuchen, die Kontrolle über eine Wickr-Identität zu übernehmen. Wickr-Identitäten basieren auf asymmetrischen Schlüsselpaaren, die zum digitalen Signieren und Überprüfen von Daten verwendet werden. Vertrauen wird hergestellt, indem die Signaturkette von einem bestimmten Objekt oder einer bestimmten kryptografischen Komponente bis zur Stammidentität oder zum Benutzer überprüft wird (z. B. Nachricht an App, App an Benutzer).

Um einen authentischen Schlüssel (oder eine Nachricht) zu erzeugen, müsste ein Angreifer einen der folgenden Schritte ausführen:

1. Erhalten Sie die private Komponente des Identitätsschlüssels eines Benutzers, mit dem Wickr-Apps authentifiziert werden können, die im Konto angemeldet sind.

2. Abrufen der privaten Komponente des Identitätsschlüssels einer App, mit der authentische ephemere Nachrichtenschlüssel erstellt und von der App gesendete Nachrichten authentifiziert werden können.

3. Einen Benutzer dazu bringen, einen gefälschten Identitätsschlüssel für einen Zielbenutzer zu akzeptieren, was den gleichen Effekt hätte wie der Erhalt des vorhandenen Identitätsschlüssels des Benutzers.

Die privaten Komponenten von App-Identitätsschlüsseln sind in einem verschlüsselten clientseitigen Datenspeicher gesichert und außerhalb der Reichweite eines serverseitigen Angreifers. Die öffentlichen Komponenten werden auf dem Server gespeichert, aber mit dem (privaten) Identitätsschlüssel des Benutzers signiert, um sie vor Manipulationen zu schützen. Benutzer dazu zu bringen, gefälschte Identitätsschlüssel zu akzeptieren, ist eher ein Social-Engineering-Angriff als ein technischer Angriff und hat wenig mit einem serverseitigen Standbein zu tun . Daher hängt die Fähigkeit des serverseitigen Angreifers, eine Authentizitätsquelle zu kompromittieren – und wirklich sein einziger technischer Angriffsweg, um die Nachrichtensicherheit zu beeinträchtigen — von seiner Fähigkeit ab, den Identitätsschlüssel eines Benutzers zu kompromittieren.

Aus verschiedenen Gründen, die hauptsächlich mit der Benutzerfreundlichkeit des Systems zusammenhängen, werden Benutzeridentitätsschlüssel auf dem Wickr-Server gespeichert und mit starker symmetrischer Verschlüsselung gesichert. Der Schutz dieser Daten ist letztendlich ein 256-Bit-Schlüssel, der eine starke kryptografische Ableitung des Kennworts des Benutzers darstellt. Dieser Schlüssel wird niemals gespeichert oder an den Server gesendet, sodass ein Angreifer, der versucht, den Identitätsschlüssel eines Benutzers zu kompromittieren, einen Angriff zum Erraten des Kennworts gegen die gespeicherte Version ausführen muss, indem er einen Algorithmus zum Generieren von Kennwortableitungen verwendet, der speziell entwickelt wurde, um den Prozess so ressourcen- und zeitaufwändig wie möglich zu gestalten. Bei nicht trivialen Passwörtern können wir erwarten, dass dieser Prozess viele Jahre bis zu vielen tausend oder Millionen von Jahren dauert, wenn der Benutzer einfach ein Qualitätspasswort mit einer Länge von nur 8 Zeichen wählt. Um mehrere Konten zu kompromittieren, müsste der Angreifer immer wieder den gleichen Aufwand betreiben. Dieses Schutzniveau bedeutet, dass serverseitige Angriffe auf Benutzeridentitätsschlüssel für alle außer den schwächsten Konten nicht durchführbar sind. Siehe Wickrs Whitepaper zum Passwortschutz.

Informationen und Metadaten

Mit der Kontrolle über den Wickr-Server hat der Angreifer Zugriff auf alle Informationen, die der Dienst über seine Benutzer hat. Bei der Entwicklung für diese Bedrohung beschränkt Wickr die Menge der von uns gespeicherten Benutzerinformationen auf das, was für die Bereitstellung eines qualitativ hochwertigen Dienstes minimal erforderlich ist. Im Folgenden finden Sie eine Liste der Benutzerkontoinformationen, die Wickr Services zum Zeitpunkt des Schreibens dieses Artikels zur Verfügung standen:

Wickr Me:

• Datum der Erstellung eines Kontos
• Gerätetyp (e), auf dem /denen ein solches Konto verwendet wurde (z. B. iOS, Android)
• Datum der letzten Verwendung
• Gesamtzahl der gesendeten / empfangenen Nachrichten
• Anzahl der mit dem Konto verbundenen externen IDs (Telefonnummern) (nicht Klartext-IDs selbst)
• Begrenzte Aufzeichnungen der letzten Änderungen an den Kontoeinstellungen (z. B. Hinzufügen oder Entfernen eines Geräts; enthält keine Nachrichteninhalte oder Routing- und Zustellinformationen)
• Wickr-Versionsnummer

Wickr Pro:

• Wickr Pro ID (E-Mail-Adresse)
• Netzwerkzugehörigkeit
• Telefonnummer, falls vom Netzwerkadministrator als zweite Form der Authentifizierung angegeben
• Datum der Erstellung eines Kontos
• Art der Geräte, auf denen ein Konto verwendet wurde
• Datum der letzten Verwendung
• Gesamtzahl der gesendeten /empfangenen Nachrichten
• Anzahl der externen IDs (Telefonnummern), die mit dem Konto verbunden die externen Klartext-IDs selbst)
• Begrenzte Aufzeichnungen der letzten Änderungen an den Kontoeinstellungen (z. B. Hinzufügen oder Entfernen eines Geräts; enthält keine Nachrichteninhalte oder Routing- und Zustellinformationen)
• Wickr-Versionsnummer
• Zahlungsbezogene Informationen
• Netzwerkeinstellungen einschließlich begrenzter Aufzeichnungen über die letzten Änderungen an den Netzwerkeinstellungen (z. B. Aktivieren oder Deaktivieren des Verbunds)

Wickr Enterprise (kundengesteuerte Bereitstellung):

• Wickr Enterprise ID (Handle)
• Netzwerkzugehörigkeit
• Datum der Erstellung eines Kontos
• Art der Geräte, auf denen ein Konto verwendet wurde
• Datum der letzten Verwendung
• Gesamtzahl der gesendeten /empfangenen Nachrichten
• Begrenzte Aufzeichnungen der letzten Änderungen an den Kontoeinstellungen (z. B. Hinzufügen oder Entfernen eines Geräts; enthält keine Nachrichteninhalte oder Routing- und Zustellinformationen)
• Wickr-Versionsnummer
• Netzwerkeinstellungen einschließlich begrenzter Aufzeichnungen der letzten Änderungen an den Netzwerkeinstellungen (z., aktivieren oder Deaktivieren der Federation)

Das Obige wäre daher im Falle eines Serverkompromisses offenlegungsgefährdet. Unsere rechtlichen Verfahrensrichtlinien und Datenschutzbestimmungen enthalten detailliertere Diskussionen darüber, wie wir die Erfassung und Verwendung von Benutzerinformationen auf unserer Plattform einschränken.

Die Kontrolle über den Server bietet einem Angreifer auch die Möglichkeit, Informationen und Metadaten zu sammeln, die der Dienst ignoriert. Die beiden besten Beispiele dafür in Wickr sind Client-IP-Adressen und Nachrichtenverfolgung.

Wickr as a Service ist völlig uninteressiert an der IP-Adresse von Wickr-Clients. Wir zeichnen sie nicht in Standardkonfigurationsanwendungsprotokollen auf oder speichern sie in Benutzerdatensätzen. Sie sind jedoch für bestimmte Komponenten der Back-End-Infrastruktur verfügbar, und unter der Annahme, dass der Angreifer die richtige Komponente kontrolliert und die richtige Verkehrs- und Korrelationsanalyse durchführt, wären diese Informationen gefährdet.

Wickr ist auch nicht daran interessiert, wer mit wem im Netzwerk kommuniziert. Wir zeichnen diese Informationen nicht in Standardkonfigurationsanwendungsprotokollen auf. Unter der Annahme, dass der Angreifer ausreichend Zeit und Mühe in den Prozess investiert, sind Anzahl, Zeiten, Arten der gesendeten und empfangenen Nachrichten sowie Quell- und Empfänger-Wickr-IDs gefährdet. Klartext-Wickr-IDs sind in Wickr Me-Datenspeichern nicht verfügbar, daher wäre diese Art der Analyse in Wickr Me weitaus schwieriger (wenn auch nicht unmöglich).

Verfügbarkeit

Während Angriffe auf die Verfügbarkeit von Diensten vielleicht nicht die interessanteste Angriffsform sind, die man sich gegen einen sicheren Messaging-Dienst vorstellen kann, haben sie sehr reale Wahrscheinlichkeiten und ziemlich offensichtliche Auswirkungen. Es gibt nicht viel zu diesem Thema in diesem Dokument zu diskutieren, außer das Risiko anzuerkennen, aber ein Angreifer mit Kontrolle über Wickr-Server hätte die Macht, Dienste zu deaktivieren und Daten zu löschen, sei es, um einfach Chaos zu verursachen oder legitimen Benutzern den Dienst zu verweigern.

Zusammenfassung

Wir hoffen, dass dieses Papier informativ für Kunden war, die die realen Auswirkungen einer Wickr-Serververletzung verstehen möchten. In Summe würde ein solches Ereignis, wenn es von einem fähigen Gegner ausgenutzt würde, potenziell Folgendes gefährden:

1. Die Sicherheit zukünftiger Nachrichten von Konten mit schwachen Passwörtern.

2. Die Vertraulichkeit begrenzter Kontoinformationen und Metadaten.

3. Die Verfügbarkeit von Diensten.

Wählen Sie hochwertige Passwörter.

Wenn hochwertige Passwörter verwendet werden, kann eine Wickr-Server-Kompromittierung (bekannt oder unbekannt) als Ereignis mit geringer oder keiner Auswirkung angesehen werden.

Betrachten Sie periodisches Rekeying.Das regelmäßige Erstellen eines neuen Schlüsselpaares und die erneute Überprüfung mit anderen (z. B. jährlich, halbjährlich) kann das Risiko eines erfolgreichen Angriffs zum Erraten von Kennwörtern weiter verringern, um den Identitätsschlüssel eines Benutzers zu gefährden. Es ist auch eine effektive Methode zur Wiederherstellung eines Benutzerkontos, von dem Sie glauben, dass es bereits durch Kennwortraten oder clientseitige Kompromittierung kompromittiert wurde. Benutzer können ihr Konto erneut eingeben, indem sie den Ablauf ‚Passwort vergessen‘ in Wickr Pro und Wickr Enterprise ausfüllen oder eine neue ID in Wickr Me erstellen.