ich möchte einen Login-Mechanismus mittels „Challenge-Response“ Verfahren und asymetrischer Verschlüsselung (RSA) realisieren:
A erzeugt eine Zufallszahl (4 Hexziffern) und sendet diese an B.
B verschlüsselt diese Zufallszahl mit seinem Public-Key zu einem Passwort und sendet das Passwort an A.
A entschlüsselt das Passwort mittels seines Private-Key.
Wenn das entschlüsselte Passwort mit der ursprünglichen Zufallszahl übereinstimmt kann sich A einloggen.
Zur Realisierung habe ich mir die „Crypto++ Library 5.5.2“ runtergeladen. Leider musste ich feststellen das ich damit nur RSA-Verschlüsselungen ab einer Schlüssellänge von 384 Bit durchführen kann. Das ist für mein Vorhaben etwas unpraktisch da ich das Passwort mündlich am Telefon übertragen muss. Bei einer Schlüssellänge von 384 Bit ergibt das eine sehr lange Sequenz. Das Passwort soll aber maximal 8 Stellen lang sein.
Nun meine Fragen:
Ist bei der Verschlüsselung von kurzen Texten (4 Hexziffern) überhaupt so ein langer Schlüssel notwendig und sinnvoll?
Gibt es C++ Quellcode für RSA der kürzere Schlüssel akzeptiert?
Wenn nicht gibt es andere asymetrische Verschlüsselungsverfahren für kurze Textsequenzen die nicht mehr als 8 Stellen verschlüsselten Text erzeugen?
ich möchte einen Login-Mechanismus mittels
„Challenge-Response“ Verfahren und asymetrischer
Verschlüsselung (RSA) realisieren:
A erzeugt eine Zufallszahl (4 Hexziffern) und sendet diese
an B.
Ist das nicht ein bisschen wenig? 4 Hex-Ziffern = 16 bit = 65536 Möglichkeiten - das ist schnell geknackt.
B verschlüsselt diese Zufallszahl mit seinem Public-Key zu
einem Passwort und sendet das Passwort an A.
A entschlüsselt das Passwort mittels seines Private-Key.
Wus? A kennt doch die Zufallszahl schon. Er/sie hat sie ja schliesslich generiert. Ausserdem hat A ja sicher nicht den private key von B, d.h. er kann das gar nicht entschlüsseln.
Wenn das entschlüsselte Passwort mit der ursprünglichen
Zufallszahl übereinstimmt kann sich A einloggen.
Wenn A sich einloggen will, musst du eher sowas machen:
B erzeugt eine Zufallszahl, verschlüsselt sie mit As öffentlichem Schlüssel, und schickt das Ergebnis an A
A entschlüsselt mit seinem private key, und schickt das Ergebnis zurück an B
B vergleicht die ursprüngliche Zufallszahl mit dem, was A geschickt hat. Wenn es übereinstimmt, betracht B A als authentifiziert.
Ist bei der Verschlüsselung von kurzen Texten (4
Hexziffern) überhaupt so ein langer Schlüssel notwendig und
sinnvoll?
Nein. Ich würde Challenge-Response mit kryptographischen Hashes machen.
Aber fürs Telefon sind die alle immer noch ein bisschen zu lang. Ich bezweifle, dass du zu einem sicheren Verfahren kommst, das so kompakt ist, dass es am Telefon funktioniert.
Ist das nicht ein bisschen wenig? 4 Hex-Ziffern = 16 bit =
65536 Möglichkeiten - das ist schnell geknackt.
Schon aber die vc++ rand() liefert nicht mehr. Ich mache nach dreimaliger Falscheingabe ein reboot. Das macht es ziemlich mühsam und ein Geldautomat hat auch nicht mehr. Ich kann aber auch mit zwei unabhängigen Zufallszahlengeneratoren arbeiten. Dann hätte ich 8 Hexziffern. Mehr sollten es aber wegen dem Telefon nicht sein.
Wus? A kennt doch die Zufallszahl schon. Er/sie hat sie ja
schliesslich generiert.
Schon aber A kennt nicht das Passwort da nur B den public-key hat. Das Passwort wird im Loginprogramm entschlüsselt und mit der uhrsprünglichen Zufallszahl verglichen.
Ausserdem hat A ja sicher nicht den
private key von B, d.h. er kann das gar nicht entschlüsseln.
Doch den hat er im Rechner abgespeichert. B hat den public-Key.
Wenn A sich einloggen will, musst du eher sowas machen:
B erzeugt eine Zufallszahl, verschlüsselt sie mit As
öffentlichem Schlüssel, und schickt das Ergebnis an A
A entschlüsselt mit seinem private key, und schickt das
Ergebnis zurück an B
B vergleicht die ursprüngliche Zufallszahl mit dem, was A
geschickt hat. Wenn es übereinstimmt, betracht B A als
authentifiziert.
Es geht mir nicht darum das A sich gegenüber B authentifiziert sondern darum das A nur von B die Berechtigung zum Login erhällt. Sowas kann ich nur durch ein Challenge-Response-Verfahren oder durch ein One-Time-Passwort realisieren. Die Lösung mit dem One-Time-Passwort wäre mir zwar lieber aber dazu muss ich auf dem Rechner von A dauerhaft etwas speichern können. Das kann ich leider nicht (Plattenloser PC wird von CD gebootet). Ausserdem bringt das für B erheblichen Verwaltungsaufwand da er nicht nur für A sondern auch für C, D, E … die Login-Berechtigung erteilen muss.
Güsse soso
Ist das nicht ein bisschen wenig? 4 Hex-Ziffern = 16 bit =
65536 Möglichkeiten - das ist schnell geknackt.
Schon aber die vc++ rand() liefert nicht mehr.
Die kann man ja zwei mal hintereinander aufrufen.
Übrigens glaube ich nicht, dass die kryptographisch gute Zufallszahlen liefert.
Ich mache nach
dreimaliger Falscheingabe ein reboot.
Damit jeder, der dein System lahmlegen will, einfach nur drei mal ein falsches Passwort eingeben muss, und dein System nur noch mit rebooten beschäftigt ist?
Das macht es ziemlich
mühsam und ein Geldautomat hat auch nicht mehr.
Was sicherheitstechnisch auch ein Faux Pas ist. Weil andere es schlecht machen heisst nicht, dass du das auch machen musst.
Versteh mich nicht falsch, ich will dir kein Paranoia-Level vorschreiben, aber wenn du hier im Mathe-Brett fragst gehe ich davon aus, dass dich die kryptographischen Aspekte interessieren. Und aus der Sicht muss ich dir einfach sagen, dass dein System so nicht sicher ist.
Wus? A kennt doch die Zufallszahl schon. Er/sie hat sie ja
schliesslich generiert.
Schon aber A kennt nicht das Passwort da nur B den public-key
hat. Das Passwort wird im Loginprogramm entschlüsselt und mit
der uhrsprünglichen Zufallszahl verglichen.
Es gibt also noch ein Paswort? Falls dich genaueres Feedback interessiert, solltest du auch ein bisschen genauer Beschreiben.
Welche Partei hat welche Schlüssel? Haben beide ein gemeinsames Geheimnis? Muss die Authentifizierung in beide Richtungen verlaufen?
Die kann man ja zwei mal hintereinander aufrufen.
Übrigens glaube ich nicht, dass die kryptographisch gute
Zufallszahlen liefert.
Zweimal hintereinander aufrufen bringt nix. Wenn man die erste kennt kann man die zweite selbst generieren. Im Übrigen ist eine Teilfolge einer Pseudozufallsfolge nicht notwendig wieder eine gute Zufallsfolge.
Ich mache nach
dreimaliger Falscheingabe ein reboot.
Damit jeder, der dein System lahmlegen will, einfach nur drei
mal ein falsches Passwort eingeben muss, und dein System nur
noch mit rebooten beschäftigt ist?
Genau das ist der Sinn. Denn es ist nicht mein System sondern das der Anderen und die wollen schlisslich damit Arbeiten. Ich will lediglich vor jedem booten das Login-Passwort zuteilen.
Versteh mich nicht falsch, ich will dir kein Paranoia-Level
vorschreiben, aber wenn du hier im Mathe-Brett fragst gehe ich
davon aus, dass dich die kryptographischen Aspekte
interessieren. Und aus der Sicht muss ich dir einfach sagen,
dass dein System so nicht sicher ist.
Eine hundertprozentige Sicherheit gibt es ohnehinn nicht. Aber gerade durch das rebooten habe ich die Möglichkeit des Knackens doch wesentlich erschwert. Passwortgeschützte RAR-Files sind übrigens aus diesem Grund ziemlich sicher da nur 3 Passworter pro Sekunde getestet werden können. Die Verzögerung ist also auch ein wesentlicher Bestandteil der Sicherheit.
Es gibt also noch ein Paswort?
Ja das hatte ich doch im ersten Posting geschrieben. Die von B mit seinem public-key verschlüsselte Zufallszahl dient A als Loginpasswort.
Vielleicht wird der Ablauf durch folgende Skitze klarer:
B A
/-- RSA =?
| |
| RSA ----- Passwort ----------\>--/
Alles was ich jetzt noch brauche ist der Source-Code einer RSA-Verschlüsselung mit kleiner Schlüssellänge.
A erzeugt eine Zufallszahl (4 Hexziffern) und sendet diese an B.
M erzeugt eine Zufallszahl Z und sendet diese im Namen von A an B.
B verschlüsselt diese Zufallszahl mit seinem Public-Key zu
einem Passwort und sendet das Passwort an A.
B denkt, dass sich A einloggen will. Er verschlüsselt Z mit dem Public-Key von A und sendet es zurück an M.
A entschlüsselt das Passwort mittels seines Private-Key.
M kann die Nachricht nicht entschlüsseln, weil er natürlich nicht im Besitz des Private-Key’s von A ist. Muss er aber auch gar nicht, denn er kennt den Inhalt der Nachricht ja sowieso: Es ist ja schließlich Z.
Soweit kann also ein beliebiger Angreifer dein Verfahren ohne Probleme durchlaufen.
Wenn das entschlüsselte Passwort mit der ursprünglichen
Zufallszahl übereinstimmt kann sich A einloggen.
Häh?
Wer überprüft denn das?
B offensichtlich ja nicht, weil A ja nichts mehr zu B schickt. Also weiß B ja überhaupt nicht, ob A wirklich A oder M ist. Inwiefern soll sich A deshalb einloggen können.
So, wie du das Verfahren beschrieben hast, weiß nach Ablauf der 5 Punkte auf jeden Fall weder A dass B wirklich B ist, noch weiß B dass A wirklich A ist.
Fazit: Nach Ablauf des Verfahrens wissen beide genau so wenig wie vorher. Das ganze Verfahren hat also absolut nichts gebracht.
So, wie du das Verfahren beschrieben hast, weiß nach Ablauf
der 5 Punkte auf jeden Fall weder A dass B wirklich B ist,
noch weiß B dass A wirklich A ist.
Ich glaube, es ist geplant, damit einen Benutzerlogin auf A zu sichern:
Also in etwa so:
A zeigt eine Zufallszahl an.
Benutzer gibt Zufallszahl an B (offenbar telefonisch)
B gibt mit PublicKey verschlüsselte Zahl zurück an Benutzer (ebenfalls telefonisch, vermutlich nach Prüfung auf Berechtigung)
Benutzer gibt so erhaltene Zahl als Passwort bei A ein
A entschlüsselt Eingabe mit PrivateKey
Wenn entschlüsselte Eingabe und ursprüngliche Zufallszahl übereinstimmen -> Login erlaubt
Der PublicKey von A müsste bei so einem Verfahren aber auch geheim bleiben und darf dem Benutzer nicht bekannt werden, sonst kann der das Passwort nämlich selbst generieren.
Das Ganze Verfahren soll nicht der gegenseitigen Authentifizierung dienen sondern dazu das B ein Loginpasswort für A vergiebt mit dem A seinen Rechner booten kann (als Alternative zu einem one-time-passwort). Da der Datenaustausch per Sprache über das Telefon läuft müsste sich ein Angreifer schon in die Telefonleitung einhacken. Das Ergebniss deines Scenarios ist das M jetzt das einmalige Loginpasswort für einen Rechner hat der Ihm nicht zur Verfügung steht und A sich nicht in seinen Rechner einloggen kann da er von M das falsche Passwort bekommen hat. Die Entschlüsselung des Passworts und der Vergleich mit der Zufallszahl findet im Loginprogramm auf dem Rechner von A statt. Die einzige Sicherheitslücke ist meiner Meinung das A das Loginprogramm hackt und die Überprüfung des Passworts überbrückt.
Gruss soso
Die kann man ja zwei mal hintereinander aufrufen.
Übrigens glaube ich nicht, dass die kryptographisch gute
Zufallszahlen liefert.
Zweimal hintereinander aufrufen bringt nix. Wenn man die erste
kennt kann man die zweite selbst generieren.
Dann ist das ein sehr schlechter Zufallsgenerator. Normalerweise haben die noch intern Informationen gespeichert, die dafür sorgen, dass sich die Zahlenfolge nicht sofort wiederholt, wenn zwei mal hintereinander die gleiche Zahl herauskommt.
Die Periodenlänge muss ja nicht auf die Anzahl der möglichen Ausgaben beschränkt sein.
Im Übrigen ist
eine Teilfolge einer Pseudozufallsfolge nicht notwendig wieder
eine gute Zufallsfolge.
Und zwei Zufallsgeneratoren sind da besser? Wo bekommst du deine Entropie eigentlich her?
Ich mache nach
dreimaliger Falscheingabe ein reboot.
Damit jeder, der dein System lahmlegen will, einfach nur drei
mal ein falsches Passwort eingeben muss, und dein System nur
noch mit rebooten beschäftigt ist?
Genau das ist der Sinn. Denn es ist nicht mein System sondern
das der Anderen
Und du kannst die zwingen, einen Reboot zu machen? Wie denn? Hast du Kontrolle über ihr System?
Es gibt also noch ein Paswort?
Ja das hatte ich doch im ersten Posting geschrieben. Die von B
mit seinem public-key verschlüsselte Zufallszahl dient A als
Loginpasswort.
Und A hat die generiert?
Vielleicht wird der Ablauf durch folgende Skitze klarer:
B A
/-- RSA =?
| |
| RSA ----- Passwort ---------->–/
Versteh ich einfach nicht, wie das sicher sein soll. Oder überhaupt funktionieren soll. Aber vielleicht bin ich einfach zu beschränkt dafür.
Alles was ich jetzt noch brauche ist der Source-Code einer
RSA-Verschlüsselung mit kleiner Schlüssellänge.
Schaum mal in die gpg sources. Da ist das für verschiedene Schlüssellängen implementiert.