Martins key.matiq-Blog
>> Zurück zum Artikelverzeichnis >>
Zero-Knowledge+ (2):
Schlüsselstreckung
Geschrieben: 03.02.2021
Letzte Überarbeitung: 22.04.2021
Stichwörter: Sicherheit
In dem Artikel "Zero Knowledge+ (1): Der 'Cautiously Knowing Service'" habe ich aufgezeigt, dass die herkömmliche "Zero-Knowledge"-Technologie der Implementierung von Virenscans und einer leistungsfähigen Suchfunktion entgegensteht und schon deshalb eine differenzierte Herangehensweise vonnöten ist.
Bei der Beschäftigung mit dem Anmeldevorgang unter der Bedingung, dass der Server Hauptkennwort und Hauptschlüssel nicht erfahren soll, ist mir aufgefallen, dass die Schlüsselstreckung bei der Verschlüsselung auf dem Client leider nicht nicht so effektiv funktioniert, wie bei der auf dem Server. Und das kann leicht zum Sicherheitsproblem werden.
Was ist "Schlüsselstreckung"?
Sollte es einer Angreifer*in gelingen, an die key.matiq-Datenbank heranzukommen, würder sie wohl versuchen, auf einem schnellen Rechner viele verschiedene Kennwörter auszuprobieren, ob sie mit diesen den Anmeldevorgang bestehen würde. Alternativ könnte sie auch versuchen von diesen Kennwörtern jeweils einen Hauptschlüssel abzuleiten und zu prüfen, ob sie damit ein Kerngeheimnis entschlüsseln kann. (Diese Art des Vorgehens nennt man "Wörterbuchangriffe".)
Beide Wege müssen wir, um sie abzuwehren, äußerst aufwändig gestalten, also möglichsts ähnlich aussichtslos, wie das direkte Ausprobieren aller möglichen Hauptschlüssel.
In dem Artikel "Das gute Kennwort" habe ich aufgezeigt, was eine Benutzer*in dazu beitragen kann. Wo es möglich ist, sollten zufällige, starke Kennwörter generiert und benutzt werden. Doch einige Kennwörter müssen halt im Kopf behalten werden. Ein zufälliges 20-Zeichen-langes Kennwort auswändig zu lernen, wäre in der Regel eine unrealistische Zumutung. Realistisch ist jedoch, ein langes komplexes, kreatives Hauptkennwort für key.matiq zu erstellen.
Die dann noch fehlende Stärke kann durch die "Schlüsselstreckung" hinzugefügt werden: Hier wird ein Algorithmus angewandt, der die Ableitung des Hauptschlüssels (und auch des Prüfwerts für die Anmeldung) so lange dauern lässt, dass die Antwortzeit bei einer normalen Anmeldung noch akzeptabel kurz ist, aber Wörterbuchangriffe deutlich erschwert werden.
Wie funktioniert eine Schlüsselstreckung?
Zutaten sind: Das Kennwort, ein "Salt"* genannter zufälliger Binärwert und ein "Hash" genannter Algorithmus, der aus einem beliebigen Ausgangswert eine zufällig erscheinende Bitfolge der gewünschten Sicherheitsstärke erstellt, aus der sich der Ausgangswert nicht zurückrechnen lässt. Schließlich noch die gewünschten Kosten (Zeit- und Speicherbedarf) für die Schlüsselberechnung.
Das Rezept ist: Ein Key-Stretching-Algorithmus, der aus den Zutaten einen Schlüssel so erstellt, dass dafür auf dem Computer eine gewisse Zeit nötig ist und es keine abkürzende Berechnung gibt.
Ein Key-Stretching-Algorithmus führt dabei den Hash-Algorithmus im einfachsten Fall eine Anzahl von Runden hintereinander aus. Allerdings könnte dann auf spezialisierter Hardware durch Parallelberechnung der Zeitaufwand wieder stark reduziert werden. Deshalb treiben neuere Key-Stretching-Algorithmen nicht nur den Zeitaufwand hoch. Die "Runden" werden dann ähnlich wie die Maschen beim Stricken miteinander so verknüpft, dass auch ein festgelegter Speicheraufwand für jede Berechnung nötig wird.
Im Ergebnis liefert jede Verdoppelung der Rechenzeit gegenüber der einzelnen Hash-Berechnung ein zusätzliches Bit an Stärke. D. h. bei 2 hoch 22 Runden liegt die Gesamtstärke der Verschlüsselung bei der Stärke des Passworts plus 22 Bits.**
Besondere Vorteile der Schlüsselstreckung
Sie liegen nicht darin, dass man jetzt einfachere Kennwörter verwenden könnte: Sobald die Schlüsselstreckung merkbare Anwortzeiten bewirkt, werden diese schnell lästiger, als ein Zeichen mehr beim Kennwort.
Aber: Alle paar Jahre verdoppelt sich immer noch die Rechenleistung neuer Computer und bewirkt damit auch die Notwendigkeit, ein Bit an Verschlüsselungsstärke hinzuzufügen, um die gleiche Sicherheit zu bewahren.
Dieses Bit kann die Schlüsselstreckung gut liefern, da im Mittel auch die Antwortzeit beim Anmelden durch höhere Rechenleistung verkürzt wird, also Rechenreserve für die Kompensation entsteht.
Es ist also durchaus möglich, über Jahre und Jahrzehnte hin, ein gutes Kennwort weiter zu verwenden (solange man es sorgfältig geheim hält), ohne dass die Gesamtstärke an Verschlüsselung schwindet. Das ist insbesondere für ältere Menschen, die unter abnehmender Merkfähigkeit leiden, wichtig.
Das geht aber nur, wenn der Service zuverlässig Schlüsselstreckung verwendet.
Wo liegen die Probleme bei der clientseitigen Verschlüsselung?
Wenn der Server soweit wie möglich Nullwissen über Geheimnisse haben soll, muss der Client, nicht der Server, die Ableitung des Hauptschlüssels vom Hauptkennwort vornehmen. Leider bieten die Browser nur für den Hash-Algorithmus nicht aber für die komplette (auch speicherfeste***) Schlüsselstreckung effiziente JavaScript-Funktionen an, weshalb letztere immer noch um Größenordnungen langsamer ist, als bei der serverseitigen Verschlüsselung.
Eine Hacker*in würde aber ihre Wörterbuch-Attacken nicht unter JavaScript ausführen, sondern auf dem schnellsten Weg, der ihr zur Verfügung steht. Wir sollten also die Gesamtstärke der Verschlüsselung nicht herunterfahren!
Der Ausweg ist, die Schlüsselstreckung etwas zurückzufahren und dafür beim Hauptkennwort ein oder zwei Zeichen mehr zu verwenden. (Das kann z. B. durch geeignete Führung der Benutzer*in beim Kennwortwechsel erreicht werden.)
Was ist aber, wenn wir im Rahmen von "Zero-Knowledge+" die clientseitige Verschlüsselung einführen, doch Hauptkennwort und Hauptschlüssel noch nicht umgestellt sind? Dann könnte das Anmelden durchaus eine Minute dauern, oder auch länger. Und der Browser meckert auch.
Selbst wenn die Schlüsselstreckung auf die langsamere Berechnung unter JavaScript umgestellt wurde, so könnte eine Benutzer*in unterschiedliche Erfahrungen unter verschiedenen Geräten machen: Bei dem einen geht die Anmeldung schnell, beim anderen dauert sie ewig lange. (Das ist ein wesentlicher Unterschied zur serverseitigen Verschlüsselung. Die Leistungsfähigkeit des Servers ist bekannt, und daher kann man dort mit der Schlüsselstreckung ohne Probleme bis zur Grenze gehen.)
Der Ausweg von "Zero-Knowledge+" (Cautiously Knowing Service): Wir bieten der Benutzer*in eine Ausnahme an. Sie kann die Ableitung des Hauptschlüssels vom Hauptkennwort ausnahmsweise vom Server durchführen lassen. Dazu fragt der Client zunächst die Benutzer*in, ob sie das gestattet. Dann schickt er das Kennwort und die anderen Parameter (Salt und Kosten) zum Server. Dieser berechnet den Schlüssel, schickt ihn zum Client zurück und vergisst dann sofort wieder das Kennwort und den errechneten Schlüssel.
Wie handhabt es der Mitbewerb?
Ich habe bislang keine Hinweise dazu gefunden. Allerdings betonen alle anderen bekannten Online-Passwortmanager, Zero-Knowledge-Server zu haben bzw. ausnahmslos die clientseitige Verschlüsselung zu benutzen. Wenn man aber keine Ausnahmen zulässt, kann man, ohne die Kund*innen zu verärgern, nur eine sehr schwache Schlüsselstreckung implementieren. Ich habe den Verdacht, dass letzteres die Regel ist. Ein Zero-Knowledge-Server hätte dann aber einen wesentlichen Sicherheitsnachteil gegenüber der serverseitigen Verschlüsselung.
Diese Überlegung bestärkt uns in dem Vorhaben, die "Zero-Knowledge-Server"-Idee als "Zero-Knowledge+" zum Cautiously Knowing Service weiterzuentwicken. Weg von irreführenden Bezeichnungen und Behauptungen, hin zu wirklichen und sichereren Lösungen.
Nächster Artikel zum Thema "Zero Knowledge+"
"Zero Knowledge+ (3): Abwehr von Erkundungsangriffen"
*) Der Salt-Wert ist nötig, damit zufällig gleiche Kennwörter immer zu verschiedenen Schlüsseln und damit auch zu verschiedenen Prüfwerten für die Anmeldung führen. Anderenfalls könnte sonst serverseitig von gleichen Prüfwerte auf gleiche Hauptkennwörter geschlossen werden, was dem angestrebten Nullwissen-Ziel des Servers widersprechen würde.
**) Die Gesamtstärke kann genaugenommen nicht über die Stärke des errechneten Schlüssels (bei uns 256 Bits) hinauswachsen. Aber soweit kommt man in Wirklichkeit ohnehin kaum.
***) In der Crypto-API gibt es zwar eine Implementation des PBKDF2-Algorithmus, aber dieser ist nicht speicherfest, d. h. er is anfällig gegenüber Entschlüsselungsversuchen mit spezialisierter Hardware, wie sie Geheimdienste benutzen. Wir hoffen, dass irgendwann einer der beiden besten speicherfesten Algorithmen (Argon2 oder SCrypt) Eingang in die Crypto-API findet. Bis dahin verwenden wir eine auf purem JavaScript basierende Implementation von SCrypt und lassen lediglich die darin enthaltenen Aufrufe des SHA-256-Algorithmus effizienter über die Cryto-API ausführen.