![[HaBo]](/styles/default/logoklein.png){kind=small}
Hallo,
durch Zufall bin ich auf folgende Artikel gestoßen und musste schon ziehmlich lachen:
h**ps://www.syss.de/fileadmin/ressources/040_veroeffentlichungen/dokumente/SySS_knackt_SanDisk_USB-Stick.pdf
h**ps://www.syss.de/fileadmin/ressources/040_veroeffentlichungen/dokumente/SySS_knackt_einen_weiteren_USB-Stick.pdf
Daraufhin hab ich mir gestern mal Gedanken gemacht wie man das besser lösen könnte. Hier meine Idee:
Wir gehen davon aus, dass der USB Stick leer und unverschlüsselt ist
1)Der User startet das Programm für Enc/Dec
2)Der User speichert seine Nutzdaten auf den USB Stick
3)Der User gibt im Programm sein Passwort ein, welches dann als 128-Bit AES Schlüssel verwendet wird (evt. Padding o.ä. damit 128 Bit entstehen)
4)Das Programm verschlüsselt die Nutzdaten auf dem USB Stick
5)Das Programm erstellt eine Datei. Wie ist erstmal uninteresant, sagen wir es handelt sich um eine einfache Textdatei mit 500 Zeichen
6)Das Programm verschlüsselt die Textdatei mit dem AES-Key und legt die unverschlüsselte sowie verschlüsselte Datei mit auf den USB Stick ab
7)Das Programm überschreibt sicherheitshalber den Speicherort des Keys mit 0 Bytes
Will man die Daten entschlüssel geschieht das folgendermaßen:
1)Man gibt ein Passwort ein
2)Das Programm entschlüsselt eine Kopie der verschlüsselte Textdatei mit dem 128-Bit AES Key, der vom Passwort abgeleitet wird (wieder evt. Padding o.ä)
3)Das Programm überprüft ob hash(foo.txt)==hash(dec(enc(foo.txt))
4)Stimmen die Hashwerte nicht überein, so gibt das Programm eine Fehlermeldung aus
5)Stimmen die Hashwerte überein, so werden die Nutzdaten des Users entschlüsselt
Meiner Meinung nach ist das System nicht so ohne weiteres angreifbar, da der richtige Key nirgendswo gespeichert wird und das Programm erstmal jedes eingegebene Passwort akzeptiert. Die Überprüfung findet dann mit Hilfe der foo.txt und enc(foo.txt) statt, wobei hier aber keine Informationen über den Key "verraten" werden.
Man könnte die Sicherheit des Systems vielleicht sogar auf die Sicherheit des verwendeten Verschlüsselungsalgorithmus reduzieren, also
Chiffre sicher -> System sicher
Mögliche Angriffe, die mir einfallen:
1)Sagen wir der Angreifer hat Zugang zu den verschlüsselten Nutzdaten sowie zu foo.txt und enc(foo.txt)
-Known Plaintext Angriff mit Hilfe von foo.txt und enc(foo.txt)
-Ciphertext only Angriff durch Nutzdaten
->Gegen beide Angriffe ist AES-128 sicher
2)Bruteforce auf das Passwort
Bei geeigneter Wahl des Passwortes aussichtslos. Ein erfolgreicher Angriff würde hier nicht die Sicherheit des Systems knacken sondern die Dummheit des Users
3)Nutzdaten unbrauchbar machen
Der Angreifer könnte das Enc/Dec Programm reversen und würde herausfinden, dass die Hashwerte von foo.txt und enc(foo.txt) verglichen werden. Er gibt irgendein Passwort ein, manipuliert das Programm so, dass gfür das falsche Passwort gilt: hash(foo.txt)==hash(dec(enc(foo.txt)). Daraufhin werden die Nutzdaten mit einem falschen Key entschlüsselt und sind danach unbrauchbar, da der Key zum entschlüsseln nirgendswo gespeichert wird.
//edit: Ein Problem konnte ich feststellen...
Das Passwort dient als 128 Bit AES Key...sollten also nur 8 Byte als Passwort eingegeben werden, so müssen diese 8 Byte nach einem festen Schema auf 16 Byte erweitert werden. Dieses Schema lässt sich natürlich reversen, wodurch eine Reduzierung des möglichen Schlüsselraums von 128 Bit auf 64 Bit erfolgt.
//edit2:
Der Schlüsselraum reduziert sich natürlich nicht von 128 auf 64 Bit, da bei eingegebenen 8/16 Byte der Schlüsselraum nicht 64/128 Bit beträgt, da der eigentliche Schlüsselraum des Passwortes nur (#Alphabet)^#Zeichen ist. Also bei 8 Byte Passwort und einem Alphabet von a...z, A...Z, 0...9->62^8 < 2^64. Um den kleineren Schlüsselraum zu kompensieren hat man natürlich 2 Möglichkeiten:
1)Man baut zusätzliche Rechenzeit in das Programm ein, so dass eine Überprüfung eines Passwortes entspechend lang dauert
2)Da wir davon ausgehen, dass ein Angreifer sowieso die Daten unbrauchbar machen kann, können wir einfach nach 10 Fehlerversuchen die Daten mit einem zufällig gewählten 128 Bit AES Key verschlüsseln, was die Daten ebenfalls unbrauchbar macht.
Dies löst natürlich noch nicht die Tatsache, dass bei einem eingegebenen Passwort <16 Byte ein Padding erfolgen muss, so dass sich der Schlüsselraum von AES auf weniger als 128 Bit reduziert, da wir davon ausgehen, dass dem Angreifer die Datei foo.txt sowie enc(foo.txt) zur Verfügung steht.
Was haltet ihr von dem Verfahren?
Hab ich irgendwo einen Denkfehler und es ist doch möglich an das Passwort zu kommen?
Irgendwelche Anregungen zur Verbesserung des Systems?
durch Zufall bin ich auf folgende Artikel gestoßen und musste schon ziehmlich lachen:
h**ps://www.syss.de/fileadmin/ressources/040_veroeffentlichungen/dokumente/SySS_knackt_SanDisk_USB-Stick.pdf
h**ps://www.syss.de/fileadmin/ressources/040_veroeffentlichungen/dokumente/SySS_knackt_einen_weiteren_USB-Stick.pdf
Daraufhin hab ich mir gestern mal Gedanken gemacht wie man das besser lösen könnte. Hier meine Idee:
Wir gehen davon aus, dass der USB Stick leer und unverschlüsselt ist
1)Der User startet das Programm für Enc/Dec
2)Der User speichert seine Nutzdaten auf den USB Stick
3)Der User gibt im Programm sein Passwort ein, welches dann als 128-Bit AES Schlüssel verwendet wird (evt. Padding o.ä. damit 128 Bit entstehen)
4)Das Programm verschlüsselt die Nutzdaten auf dem USB Stick
5)Das Programm erstellt eine Datei. Wie ist erstmal uninteresant, sagen wir es handelt sich um eine einfache Textdatei mit 500 Zeichen
6)Das Programm verschlüsselt die Textdatei mit dem AES-Key und legt die unverschlüsselte sowie verschlüsselte Datei mit auf den USB Stick ab
7)Das Programm überschreibt sicherheitshalber den Speicherort des Keys mit 0 Bytes
Will man die Daten entschlüssel geschieht das folgendermaßen:
1)Man gibt ein Passwort ein
2)Das Programm entschlüsselt eine Kopie der verschlüsselte Textdatei mit dem 128-Bit AES Key, der vom Passwort abgeleitet wird (wieder evt. Padding o.ä)
3)Das Programm überprüft ob hash(foo.txt)==hash(dec(enc(foo.txt))
4)Stimmen die Hashwerte nicht überein, so gibt das Programm eine Fehlermeldung aus
5)Stimmen die Hashwerte überein, so werden die Nutzdaten des Users entschlüsselt
Meiner Meinung nach ist das System nicht so ohne weiteres angreifbar, da der richtige Key nirgendswo gespeichert wird und das Programm erstmal jedes eingegebene Passwort akzeptiert. Die Überprüfung findet dann mit Hilfe der foo.txt und enc(foo.txt) statt, wobei hier aber keine Informationen über den Key "verraten" werden.
Man könnte die Sicherheit des Systems vielleicht sogar auf die Sicherheit des verwendeten Verschlüsselungsalgorithmus reduzieren, also
Chiffre sicher -> System sicher
Mögliche Angriffe, die mir einfallen:
1)Sagen wir der Angreifer hat Zugang zu den verschlüsselten Nutzdaten sowie zu foo.txt und enc(foo.txt)
-Known Plaintext Angriff mit Hilfe von foo.txt und enc(foo.txt)
-Ciphertext only Angriff durch Nutzdaten
->Gegen beide Angriffe ist AES-128 sicher
2)Bruteforce auf das Passwort
Bei geeigneter Wahl des Passwortes aussichtslos. Ein erfolgreicher Angriff würde hier nicht die Sicherheit des Systems knacken sondern die Dummheit des Users
3)Nutzdaten unbrauchbar machen
Der Angreifer könnte das Enc/Dec Programm reversen und würde herausfinden, dass die Hashwerte von foo.txt und enc(foo.txt) verglichen werden. Er gibt irgendein Passwort ein, manipuliert das Programm so, dass gfür das falsche Passwort gilt: hash(foo.txt)==hash(dec(enc(foo.txt)). Daraufhin werden die Nutzdaten mit einem falschen Key entschlüsselt und sind danach unbrauchbar, da der Key zum entschlüsseln nirgendswo gespeichert wird.
//edit: Ein Problem konnte ich feststellen...
Das Passwort dient als 128 Bit AES Key...sollten also nur 8 Byte als Passwort eingegeben werden, so müssen diese 8 Byte nach einem festen Schema auf 16 Byte erweitert werden. Dieses Schema lässt sich natürlich reversen, wodurch eine Reduzierung des möglichen Schlüsselraums von 128 Bit auf 64 Bit erfolgt.
//edit2:
Der Schlüsselraum reduziert sich natürlich nicht von 128 auf 64 Bit, da bei eingegebenen 8/16 Byte der Schlüsselraum nicht 64/128 Bit beträgt, da der eigentliche Schlüsselraum des Passwortes nur (#Alphabet)^#Zeichen ist. Also bei 8 Byte Passwort und einem Alphabet von a...z, A...Z, 0...9->62^8 < 2^64. Um den kleineren Schlüsselraum zu kompensieren hat man natürlich 2 Möglichkeiten:
1)Man baut zusätzliche Rechenzeit in das Programm ein, so dass eine Überprüfung eines Passwortes entspechend lang dauert
2)Da wir davon ausgehen, dass ein Angreifer sowieso die Daten unbrauchbar machen kann, können wir einfach nach 10 Fehlerversuchen die Daten mit einem zufällig gewählten 128 Bit AES Key verschlüsseln, was die Daten ebenfalls unbrauchbar macht.
Dies löst natürlich noch nicht die Tatsache, dass bei einem eingegebenen Passwort <16 Byte ein Padding erfolgen muss, so dass sich der Schlüsselraum von AES auf weniger als 128 Bit reduziert, da wir davon ausgehen, dass dem Angreifer die Datei foo.txt sowie enc(foo.txt) zur Verfügung steht.
Was haltet ihr von dem Verfahren?
Hab ich irgendwo einen Denkfehler und es ist doch möglich an das Passwort zu kommen?
Irgendwelche Anregungen zur Verbesserung des Systems?
Zuletzt bearbeitet:
