Abwehr von Erkundungsangriffen
Erkundungsangriffe bei der Anmeldung
Bei der Authentisierung über einen Zero-Knowledge-Beweis fragt zunächst der Client den Server nach dem Salt-Wert für eine Box. Aus dem Salt und dem (nur dem Client bekannten Kennwort) wird ein Schlüssel gebildet, aus dem ein Prüfwert abgeleitet wird, der zum Server übertragen wird und dessen korrekter Wert (also beim korrekten Kennwort) dem Server bekannt ist. An der Übereinstimmung von dem vom Client gesandten Prüfwert mit dem vom Server gespeicherten Prüfwert erkennt der Server, ob der Client das richtige Kennwort kennt oder nicht, d. h. ob die Anmeldung akzeptiert wird oder nicht.
Die Salt-Werte sind nötig, um unterschiedliche Prüfwerte auch bei gleichen Kennworten für verschiedene Boxen zu erhalten. (Sonst könnte der Server erkennen, welche Boxen gleiche Hauptkennworte verwenden.) Ein-Salt-Wert kann nur nach einer erfolgreichen Anmeldung geändert werden. Daher sind gleiche Salt-Werte bei mehreren Anfragen an dieselbe Box ein Indiz dafür, dass die angefragte Box (über den Namen oder die E-Mail-Adresse identifiziert) tatsächlich existiert.
Die Abwehr besteht darin,
- dieses Indiz zu entwerten, also auch bei nicht belegten Boxnamen bzw. E-Mail-Adressen zunächst gleiche Salt-Werte an den Client zurückzugeben (auch wenn die Anmeldung dann später scheitern wird, denn die Angreifer*in soll weder aus dem Verfahren noch aus dem Timing erkennen können, woran es lag) und
- die Anzahl der Angriffe zu minimieren, indem für die Einleitung der Anmeldung Mensch-Maschine-Filter (Captcha) durchlaufen wird, sofern nicht das "box_id"-Cookie (bzw. "ticket_id"-Cookie) beweist, dass dem Client bereits die Box (bzw. das Ticket) bekannt ist.
Fake-Accounts
Um bei aufeinanderfolgenden Anmeldeversuchen an gleiche nicht-existierenden Boxen (oder auch Tickets) gleiche Salt-Werte liefern zu können, müssen diese gespeichert werden. Dazu werden Fake-Accounts generiert, die sich Angreifer*innen gegenüber kaum von tatsächlichen Boxen oder Tickets unterscheiden lassen.
Fakes für Boxen
Boxen ändern die Salt-Werte nach einiger Zeit: Regelmäßig nach einem Monat bei der nächsten erfolgreichen Anmeldung, falls es jedoch eine möglichen Angriff auf die Box gab, direkt bei der nächsten erfolgreichen Anmeldung.
Fakes müssen daher ähnliche Intervalle erfolgreicher Anmeldungen simulieren, um die gleiche Häufigkeitsverteilung von Salt-Wechseln zu erreichen.
Das Einfachste bei Boxen ist, sich eine reale Box zum Vorbild zu nehmen und dann als "Schatten" dieser Box zu agieren: Wenn beim Vorbild eine erfolgreiche Anmeldung erfolgt, bewirkt dies beim Schatten, dass beim nächsten Anmeldeversuch dem Angreifer ein neuer Salt-Wert präsentiert wird, also ein vorheriger Salt-Wechsel durchgeführt wird.
Wird eine reale Box gelöscht, so werden auch alle ihre Schatten gelöscht, d. h. beim nächsten Angriff (auf den gelöschten Fake) würde ein neuer Fake mit einem anderen Vorbild erstellt, genauso wie reagiert würde, wenn eine reale Box gelöscht würde und auf diese danach eine Anmeldung versucht würde.
Risikobetrachtung
Das Risiko besteht darin, dass eine Angreifer*in feststellen könnte, dass sich eine Gruppe von Accounts ähnlich bezüglich der Salt-Wechsel verhalten. Sie könnte jedoch nicht feststellen, welcher der Accounts einer realen Box zuzuordnen ist, welche Account lediglich Schatten der Box sind.
Der Informationsgewinn würde sich auf Zeitintervalle in denen es wahrscheinlich Anmeldezeitpunkte der realen Box gab (oder ggf. die Box gelöscht wurde) beschränken.
Das Risiko kann minimiert werden, indem Anmeldeversuche an Fakes statistisch erfasst werden und dementsprechend ggf. der Mensch-Maschine-Filter verschärft wird, so dass die Erkennung von Real-Box- und Schatten-Gruppen mangels ausreichender Zahl von Messungen möglichst unterbunden wird.
Das Risiko könnte verschärft werden, wenn es der Angreifer*in gelänge, die reale Box zu identifizieren. Deshalb werden bei Box-Registrierungen und Namensänderungen von Boxen auch solche Registrierungen und Namenänderungen abgelehnt, die Namen (oder E-Mail-Adressen) verwenden, die von Fake-Accounts belegt sind.
Ein weiteres Risiko besteht, dass aus der Größe von identifizierten Box-und-Schatten-Gruppen eine Angreifer*in abschätzen könnte, wie viele Boxen insgesamt beim key.matiq-Dienst registriert sind. Doch diese Information könnte er vermutlich auch aus anderen Quellen (z. B. den Umsätzen der matiq UG) erhalten und das Risiko ist eher der Industriespionage zuzuordnen als der Offenlegung personenbezogener Daten. Damit können wir leben.
Fakes für Tickets
Tickets sind kurzfristige Accounts. Sie werden in Stunden bis Tagen abgearbeitet und die Login-Möglichkeit besteht danach noch sieben weitere Tage. Ein Salt-Wechsel ist in dieser Zeit nicht vorgesehen.
Die Fakes werden also während ihrer Lebensdauer keinen Salt-Wechsel vollziehen. Die Lebensdauer wird so gewählt, dass die Abarbeitungszeit einer logarithmischen Normalverteilung folgt (Mittelwert und Standardabweichung der Logarithmen folgen den typischen Werten für Tickets) und die sieben weiteren Tage aufaddiert werden.
Risikobetrachtung
Das Risiko der Identifizierung eines existierenden Tickets ist wegen der kurzen Lebensdauer sehr gering. Nochmals weit geringer ist das Risiko, dass die evtl. gewonnene Information vom Hacker innerhalb der gut sieben bis meist maximal 14 Tage Lebenszeit eines Ticket-Accounts verwertet werden könnte.
(Das Ticket selbst besteht zu Dokumentationszwecken zwar noch ca. ein Jahr weiter, aber es ist keine Anmeldung von außen her mehr möglich, daher sprechen wir hier von der Lebenszeit des Ticket-Accounts.)
Zudem wählt die für die Anmeldung erforderliche Ticketnummer nicht die Benutzer*in, sondern der Service, so dass hier auch über die Registrierung oder Änderungen keine zusätzlichen Angriffspunkte bestehen.
Siehe auch
In dem Blog-Artikel "Zero-Knowledge+ (3): Abwehr von Erkundungsangriffen" wird diskutiert, dass die Zero-Knowledge-Technologie, falls keine Abwehrmaßnahmen getroffen werden, Erkundungsangriffe ermöglicht, die Hacker*innen erlauben, festzustellen, ob ein Anmeldekonto (Box oder Ticket) existiert oder nicht.