Martins key.matiq-Blog

>> Zurück zum Artikelverzeichnis >>


Zero-Knowledge+ (3):
Abwehr von Erkundungs-Angriffen

Geschrieben: 03.02.2021
Letzte Überarbeitung: 22.04.2021
Stichwörter: Angriffe, Sicherheit, Sicherheit mit Bedienbarkeit

In dem Artikel "Zero Knowledge+ (2): Schlüsselstreckung" habe ich dargelegt, dass sorgfältig darauf geachtet werden muss, im Zuge der Umstellung auf die clientseitiger Verschlüsselung keine Schwachstellen einzubauen. Eine Abschwächung der Schlüsselstreckung ohne entsprechende Stärkung des Hauptkennworts würde eine Schwächung bedeuten.

Ebenfalls wäre es eine Schwächung, wenn Hacker*innen die Schlüsselableitung auf dem Client nutzen könnten, um Erkundungsangriffe (Reconnaissance Attacks) zu fahren, insbesondere um festzustellen, ob für einen bestimmten Namen (oder eine E-Mail-Adresse) eine Box existiert oder nicht.

Welcher Angriffspunkt ist denkbar?

Dazu muss man wissen, wie bei Verwendung bei der Zero-Knowledge-Technologie im Gutfall eine Anmeldung des Clients beim Server funktioniert:

  • Der Client holt sich von der Nutzer*in über das Anmeldeformular Boxnamen (oder E-Mail-Adresse) und Hauptkennwort (und möglicherweise noch einen Anmeldeschlüssel für die 2-Faktor-Authentisierung).
  • Der Client teilt dem Server Boxnamen bzw. E-Mail-Adresse mit und fragt nach dem Salt-Wert1 und den Streckungsparametern (Anzahl Runden etc.) die er für die Schlüsselstreckung benötigt.
  • Der Server teilt dem Client die benötigten Werte mit, und der Client errechnet daraus einen ersten Schlüssel2, aus dem er dann noch einen Prüfwert berechnet, den er dem Server zusammen mit dem Boxnamen (bzw. der E-Mail-Adresse)3 und ggf. dem Anmeldeschlüssel für die 2-Faktor-Authentisierung mitteilt.
  • Der Server überprüft jetzt,
    • ob es die angefragte Box überhaupt gibt,
    • ggf. ob der Prüfwert stimmt und
    • ob bei 2-Faktor-Authentisierung das entsprechende Cookie gesetzt ist, oder aber ob ein Authentisierungs-Schlüssel übergeben wurde und dieser auch passt.
  • Nur wenn alles stimmt, ist die Anmeldung erfolgreich, sonst nicht.
  • Ist die Anmeldung fehlgeschlagen, wird der Grund keinesfalls direkt dem Client mitgeteilt, sondern der Box-Besitzer*in nur über eine E-Mail (sofern sie eine Adresse angegeben hat). Dem Client wird nicht getraut, denn er konnte seine Berechtigung ja noch nicht nachweisen. Er könnte einer Angreifer*in gehören.

Die Antwortzeit des Servers sollte bei einem Fehler unabhängig vom Grund sein (um Timing-Angriffe zu Erkundungszwecken abzuwehren): Egal ob es die Box nicht gibt, ob der Prüfwert falsch war oder die 2-Faktor-Authentisierung nicht passte. Diesbezüglich gibt es keinen Unterschied zwischen clientseitiger oder serverseiter Verschlüsselung.

Das Problem ist aber, dass der Client einen Salt-Wert benötigt. Für eine existierende Box gibt es ihn und er kann nicht außerhalb einer angemeldeten Sitzung geändert werden.4

Keine Lösung wäre es, einfach für nicht existierende Boxen jeweils einen Salt-Wert neu zu erzeugen: Eine Angreifer*in könnte nämlich Salt-Werte für mehrere Boxen mehrfach abfragen. Wenn er für Box B1 mehrfach hintereinander den gleichen Salt-Wert S1 bekommt, für die Box B2 jedoch hintereinander verschiedene Salt-Werte S21, S22, ... erhält, so könnte er daraus schließen, dass die Box B1 existiert, die Box B2 aber nicht.

Ebenfalls keine Lösung wäre es, einfach für alle nicht-existierenden Boxen ein und denselben Salt-Wert bereitzuhalten. Das könnte einer Angreifer*in ebenso schnell die gewünschte Information geben, weil existierende Boxen alle verschiedene Salt-Werte haben müssen.

Warum gibt es die Salt-Werte? Warum müssen sie verschieden sein?

Aus dem Salt-Wert und dem Hauptkennwort wird (über den Zwischenschritt Schlüsselstreckung) letztlich der Prüfwert gebildet. Salt und Prüfwert werden auf dem Server abgespeichert. Der Salt, um ihn dem Client mitzuteilen, der Prüfwert, um überprüfen zu können, ob der Client den Prüfwert richtig berechnen konnte, denn nur dann kann er annehmen, dass der Client auch das Hauptkennwort kannte.

Würde der Server für alle Boxen dieselben Salt-Werte verwenden (oder gar keine), könnte er feststellen, welche Boxen gleiche Kennwörter verwenden (wenn gleiche Prüfwerte herauskommen, wären die Kennwörter ebenfalls gleich). Der Server soll so etwas aber nicht wissen. Es würde dem Prinzip "sowenig Wissen wie möglich" widersprechen.

Was sagen andere zu dem Problem?

Ich habe leider nichts dazu gefunden. Suchmaschinen liefern zur Anfrage "zero knowledge reconnaissance attack" entweder Ergebnisse zu "zero knowledge" oder zu "reconnaissance attack", nicht aber zu "reconnaissance attack" in Verbindung mit "zero knowledge". Ich vermute, dass dies daran liegt, dass die Anzahl von Web-Services mit Zero-Knowledge-Technologie noch recht überschaubar ist.

Vielleicht haben auch noch gar keine Erkundungsangriffe in der oben beschriebenen Weise stattgefunden, oder sie wurden noch nicht entdeckt. Es ist aber durchaus möglich, dass z. B. staatliche Geheimdienste solche Angriffe bereits durchführen, aber tunlichst nicht davon sprechen, um die angegriffenen Service-Betreiber*innen in Sicherheit zu wiegen.

Ist das Problem überhaupt wichtig und dringend?

Fest steht: Die beschriebenen Erkundungsangriffe sind möglich. Und sie sind leichter durchzuführen als Erkundungsangriffe, denen auch Nicht-Zero-Knowledge-Server ausgesetzt sein können (weil sie eine Registrierung erfordern5).

Selbst wenn sich Erkundungsangriffe sich nicht zu 100% verhindern lassen sollten, und Boxen vor allem über starke Hauptkennworte geschützt werden sollten, so handelt es sich doch bei Box-Namen und E-Mail-Adressen um personenbezogene Daten, die anonymen Angreifer*innen nicht leichtfertig ausgeliefert werden dürfen. Das von den Hacker*innen dabei gesammelte Wissen lässt sich, wenn sie stattgefunden haben, nicht mehr leicht zurückholen. Deshalb gilt es, proaktiv zu handeln und, bevor man bei Anmeldungen clientseitige Verschlüsselung verwendet, Abwehrmaßnahmen zu implementieren. Sonst hat man leicht im Ergebnis zwar Nullwissen bei den Servern, aber angesammeltes Wissen bei den Hacker*innen!

Welche Lösungsmöglichkeiten gibt es?

Es müssten Fake-Accounts (Pseudo-Anmeldekonten) gebildet werden: Wenn eine Box angefragt wird, die es nicht gibt, und für die es auch noch keinen Fake-Account gibt, müsste ein solcher angelegt werden. Er beinhaltet dann als Daten Boxname bzw. E-Mail-Adresse, den Salt-Wert, wann der Salt gewechselt werden soll sowie eine Zusammenfassung der bisherigen Angriffe6, die irgendwann erlaubt, zu entscheiden, dass der Fake-Account nicht mehr benötigt wird, weil schon lange nicht mehr auf ihn zugegriffen wurde.

Die Lebensdauer des Salts eines Fake-Accounts ist so zu wählen, dass sie der Lebensdauer des Salts einer normalen Box entspricht. "Entspricht" bedeutet hier: Die statistische Verteilung muss gleich sein. Die Angreifer*in darf aus verschiedenen Proben keine Wahrscheinlichkeit dafür errechnen können, ob eine Box existiert oder nicht.

Eine reale Box wird normalerweise nach Erstellung eines Salts erst einen Monat und dann die nächste Anmeldung abwarten, bevor ein neuer Salt erstellt wird.

Damit jetzt die Fake-Accounts keine zu hohe Lebendauer haben müssen, kann man für Boxen, die seit der letzten Anmeldung möglicherweise angegriffen wurden7, die Frist von einem Monat fallen lassen, also den Salt beim nächsten Login auf jeden Fall wechseln.

Um einen Fake-Account gegenüber einer Angreifer*in realistisch erscheinen zu lassen, bieten sich zwei Möglichkeiten an:

  • Modell: Man kann ein mathematisches Modell für die statistische Verteilung der Anmeldeabstände eines Anmeldekontos entwickeln.
  • Schatten: Man kann für einen Fake-Account mit dem Zufallzahlengenerator eine echte Box als "Vorbild" auswählen: Immer dann, wenn sich die Besitzer*in des Vorbilds anmeldet, könnte der Fake-Account (wie es das Vorbild für sich tut) überprüfen, ob die Voraussetzungen für einen Salt-Wechsel gegeben sind. Also, ob der Salt-Wert schon einen Monat existiert oder ob es einen Angriff auf den Fake-Account gegeben hat. Eine echte Box hätte also bei dieser Alternative keinen, einen oder mehrere Fake-Accounts als Schatten, die sich nur hinsichtlich der möglichen Salt-Wechsel-Zeitpunkte mit der Box gleichen. (Gewiss wäre dieses Verfahren hinsichtlich möglicher Risiken genau zu überdenken.)

Das Bestechende an der zweiten Alternative ist, dass sie sehr einfach ist und dass sie gewiss eine realistische Wahrscheinlichkeitsverteilung für den Salt-Wechsel ergibt.

Zu bedenken ist allerdings, dass die Salt-Wechsel häufig synchron mit der realen Box stattfinden. Eine Angreifer*in könnte also theoretisch erkennen, dass hier zwei Konten zusammenhängen, sollte er beide regelmäßig angreifen. Sie wüsste aber erst, welches von beiden das reale Anmeldekonto ist, wenn der Fake-Account gelöscht wird. Dazu müsste sie aber langfristig Daten über die beiden Konten sammeln, dann lange die beiden in Ruhe lassen und schließlich wieder auf sie zugreifen, wiederum länger Daten sammeln, um festzustellen, dass das eine Anmeldekonto sein Verhalten nicht oder wenig geändert hat (also vermutlich eine existierenden Box ist), das andere aber nun in ganz anderen Abständen seinen Salt-Wert ändert (also vermutlich ein Fake-Account ist). Dennoch könnte sie sich nicht ganz sicher sein und die Datensammlung könnte vom Server auch ausgebremst werden, als Nebeneffekt der weiter unten beschriebenen Abwehrmaßnahmen gegen DoS-Angriffe. (Vielleicht gelingt es ja auch mit diesen Abwehrmaßnahmen, die Löschung von Fake-Accounts, die als "Schatten" zu einer realen Box existieren, völlig zu vermeiden, solange die reale Box nicht gelöscht wird. Dann hätte die Angreifer*in keine Chance mehr zu erkennen, welches Anmeldekonto real und welches gefaked ist.)

Die erste Alternative, das mathematische Modell, ist nicht ganz unkompliziert, aber durchaus machbar: Man müsste eine Statistik über die Anmeldeabstände führen, würde vermutlich herausbekommen, dass die einen sich häufiger anmelden, die anderen seltener. Sie dürften im Wesentlichen einer logarithmischen Normalverteilung folgen.8

Genauer: key.matiq müsste wohl zunächst für jeden Fake-Account ein "Profil" erstellen und zufällig (entsprechend der Wahrscheinlichkeitsverteilung) einen Mittelwert und eine Varianz der Anmelde-Abstände wählen, so dass es eine Wahrscheinlichkeitsverteilung für dieses Anmeldekonto gibt. Nach dieser Wahrscheinlichkeitsverteilung wird dann nach jeder Pseudo-Anmeldung der nächste Anmelde-Zeitpunkt zufällig gewählt.

Es kommt bei dem Modell vermutlich gar nicht darauf an, es möglichst perfekt zu gestalten, sondern bereits eine einfache Variante würde den Aufwand für eine Hacker*in bereits hochtreiben.9 Wenn sie auf entsprechende Widerstände bereits bei den Erkundungsangriffen stößt, ist dies für sie auch ein Signal, dass sie sich bei echten Angriffen die Zähne ausbeißen wird. Die Zahl der Hacker*innen, die dann noch weitermachen, wird sich schon stark reduzieren. Und wir haben die Chance, diese genau zu beobachten und Gegenmaßnahmen zu ergreifen.

Wie schützen wir key.matiq
bei der Erstellung von Fake-Accounts
vor DoS-Angriffen?

Es kann natürlich sein, dass eine Angreifer*in key.matiq geradezu herausfordert, viele Fake-Accounts zu bilden, um das System übermäßig zu belasten, so dass der key.matiq-Service nicht mehr wie gewohnt verfügbar ist. Deshalb haben wir ja auch schon diskutiert, Fake-Accounts nach einiger Zeit wieder zu löschen.

Abwehrmaßnahmen sind denkbar, sollen aber normale Benutzer*innen nicht belasten. Deshalb achten wir zunächst darauf, wann keine Abwehrmaßnahmen erforderlich sind:

Wenn sich eine Benutzer*in schon einmal von dem Gerät und Browser in key.matiq angemeldet hatte, wird ja ein Cookie gesetzt, das verschlüsselt die Box-ID beinhaltet. Wenn dieses Cookie existiert und die Box-ID zu der Box passt, an die neu angemeldet werden soll, dann können wir zunächst auf Abwehrmaßnahmen verzichten. Wird aber von einem Client aus das box_id-Cookie präsentiert und es wird damit wiederholt falsch angemeldet, sollten wohl die Abwehrmaßnahmen doch erfolgen (evtl. wurde das box_id-Cookie von der Angreifer*in gestohlen).

Als Abwehrmaßnahmen sind denkbar: Mensch-Maschine-Filter (Captcha) und Proof-of-Work (dem Client eine Rechenaufgabe stellen, um ihn zu belasten und damit auszubremsen).

Möglicherweise ist es damit möglich, Fake-Accounts eine ebensolange Lebensdauer wie realen Boxen zu geben, ohne den Server übermäßig zu belasten. Sollte die Zahl der Fake-Accounts wesentlich ansteigen, könnten die Abwehrmaßnahmen (Captcha und Proof-of-Work) verschärft werden. Wichtig ist halt, die Belastung durch Fake-Accounts automatisch zu beobachten und ggf. entsprechende Warnhinweise zu erstellen.

Tickets

Neben Boxen können natürlich Ticket-Logins angegriffen werden. Den Angriffen kann aber analog zu denen auf Boxen entgegengegtreten werden. Wir brauchen lediglich zusätzlich zum box_id-Cookie ein "ticket_id"-Cookie.

Tickets sind allerdings eher die Ausnahme und kurzlebig. Daher sind möglicherweise Vereinfachungen möglich.

Wie gehen wir jetzt vor?

Wir nehmen zunächst die einfachste Lösung: Die Schatten-Variante für Fake-Accounts. Die Fake-Accounts werden erst gelöscht, wenn die zugehörigen realen Boxen gelöscht werden (deshalb sehen wir hier keine unvertretbaren Risiken). Gleichzeitig bremsen wir mit Captchas Angreifer*innen aus, und hoffen, damit bereits DoS-Angriffe genügend abgewehrt zu haben. Durch ein entsprechendes Monitoring wird das ständig überprüft.

Bei Tickets gehen wir weitgehend analog vor. Allerdings müssen wir hier auf die Modell-Variante ausweichen, wenn es gerade kein Ticket gibt. Ein sehr einfaches Modell, dass einem typischen Ticket entspricht, sollte reichen. Wir führen das "ticket_id"-Cookie ein, um Angriffe ohne Belastung für die wirklichen Nutzer*innen ausbremsen zu können und wir überprüfen über das Monitoring, inwieweit Angriffe auf Tickets überhaupt noch stattfinden.

Sollten diese Verfahren nicht ausreichen, werden wir in allen Fällen die Modell-Variante verwenden. Die Komplexität des Modells wird sich dabei daran orientieren, welche Form und Intensität von Erkundungsangriffen wir registrieren.

Wir denken, dass wir so genügend Vorsorge treiben, den Aufwand aber auf das Nötige beschränken. (Schließlich gibt es ja immer auch andere wichtige Punkte, die bearbeitet werden wollen.)

Nächster Artikel zum Thema "Zero Knowledge+"

"Zero Knowledge+ (4): Schutzniveaus"

1) Das ist ein zufällig gewählter Wert, der mit dem Hauptkennwort kombiniert wird, bevor beide zusammen den Schlüsselableitungs-Algorithmus (Schlüsselstreckung) durchlaufen.

2) Möglicherweise lässt der Client auf Veranlassung der Kund*in hin die Berechnung durch den Server ausführen

3) Der Boxname wird hier zum zweiten Mal gesendet. Natürlich ist auch denkbar, dass sich der Server den Boxnamen von der ersten Anfrage gemerkt hat.

4) Die Änderung des Salt-Werts bewirkt, dass der Prüfwert für die Anmeldung und auch der Hauptschlüssel geändert werden müssen. Dafür wird aber auch dass Hauptkennwort benötigt.

5) Natürlich gehen wir auch diese möglichen Angriffspunkte an. Ich bespreche sie aber hier nicht näher, weil sie unabhängig davon bestehen, ob die Nullwissen-Strategie für den Server verfolgt wird oder nicht.

6) Zumindest den Zeitpunkt des letzten Angriffs, aber vielleicht auch die Zahl der Angriffe, deren mittleren Abstand und die Varianz der Abstände.

7) Von einem möglicher Angriff kann man ausgehen, wenn eine erfolglose Anmeldung versucht wurde, der nicht bald von derselben IP-Adresse aus eine erfolgreiche folgte.

8) Es gibt als Besonderheit den Effekt, das manche Nutzer*innen kurz nach einer Anmeldung, weil sie etwas vergessen haben, noch eine zweite oder dritte Anmeldung durchführen, aber dies hat kaum Auswirkungen auf den Salt-Wechsel, so dass dieser Effekt zumindest zunächst vernachlässigbar ist. Ansonsten dürfte die Anzahl der kurzfristigen Folgeanmeldungen einer Bernoulli-Verteilung folgen. Die Abstände der Folgeanmeldungen wären jedoch genauer zu untersuchen. (Sicherlich gibt es Nutzer*innen, die bei der ersten Anmeldung schon die meiste Arbeit erledigt haben und bei der zweiten nur etwas nachschieben. Andere wollten vielleicht zunächst nur schnell etwas nachsehen und dann ist ihnen eingefallen, dass sie mal aufräumen könnten und melden sich noch einmal und nun für längere Zeit an ...) Also man könnte das Modell noch beliebig verkomplizieren. Doch es ist vermutlich nicht nötig.

9) Man sollte daran denken: Die Hacker*innen wissen nicht mehr, als in diesem Artikel beschrieben ist. Sie kennen keine Statistik über die Anmelde-Abstände, sie haben höchstens Vermutungen. Wenn wir uns nicht ganz blöd anstellen, sind die Hacker*innen kaum in der Lage einen Fake-Account von einer realen Box zu unterscheiden, selbst wenn die Salt-Wechsel-Abstände nicht ganz denen realer Boxen entsprechen. Wir als Betreiber*innen eines Web-Services können dagegen die Statistik erfassen, das Verhalten von Fake-Accounts nachbessern, wissen viel mehr über das reale Verhalten der Benutzer*innen und sind damit den Hacker*innen weit voraus.


>> Zurück zum Artikelverzeichnis >>