Moin, die Frage ist eher eine Interessensfrage, es geht um's Prinzip. Gibt es eine mathematisch einigermaßen sichere Methode, um aus einer Zufallszahl und einem Schlüssel von Hand eine TAN zu generieren? Ich denke da an irgendein Gerät G, das durch einen Schlüssel gegen Zugriff geschützt ist. Als Beispiel nehmen wir einfach eine vierstellige Zahl an. Der Besitzer B gibt seinen Schlüssel ein und kann das Gerät einstellen, verändern, öffnen oder was sonst noch. Jetzt soll es aber möglich sein, dass ein Dritter D das Gerät einmalig bedient, wenn B nicht anwesend ist, ohne dass D den 'Hauptschlüssel' erfährt mit dem er ständig Zugriff auf G hätte. Die Idee dazu wäre, dass D an G eine Taste drückt, worauf G eine zufällige Zahl anzeigt. Diese Zahl gibt D an B weiter, der daraus mithilfe seines Schlüssels eine TAN berechnet und diese an D zurückschickt. D gibt die TAN ein und hat Zugriff auf G. Danach ist die TAN ungültig und D müsste für erneuten Zugriff eine neue Zufallszahl generieren lassen. Es soll natürlich möglichst schwer sein, mit Hilfe der Zufallszahl und der TAN den Schlüssel zu berechnen. Eigentlich hätte ich das für nicht möglich gehalten, da ich dachte, dass ein Computer alles, was man von Hand verschlüsseln kann, innerhalb kurzer Zeit brechen kann, aber nachdem ich vom Doppelwürfel erfahren habe, interessiert es mich mal, ob meine Idee auch funktionieren würde. Vielleicht gibt es ja eine konstruktive Diskussion mit sinnvollen Ansätzen. Danke dafür schonmal :-)
Als Ergänzung: Es muss natürlich für G leicht möglich sein, die TAN ebenfalls zu berechnen oder zu überprüfen.
Schwierig. Einfache Rechenoperationen sind meist auch einfach umkehrbar. Also z.B. einen vierstelligen Schlüssel addieren (Überlauf ignorieren/wegwerfen); da ist klar, daß der Angreifer nur ein Paar aus Zufall und TAN braucht, um den Schlüssel zu berechnen. Wenn man jetzt zusätzlich noch eine Multiplikation ins Spiel bringt, braucht der Angreifer eben zwei Beispiele, um den Schlüssel zu berechnen. Und fortgeschrittene Ahnung von modulo-Arithmetik, weil bei der Multiplikation mehr Übertrag entsteht und weggeworfen wird. Es geht allerdings auch ohne Mathematik: Man bereitet eine Liste von zufällig gewählten TANs, speichert die in der Maschine, und druckt sie einmal aus, für B. Die Maschine sucht sich dann zufällig eine noch nicht benutzte TAN aus, gibt D die Listenposition, und B kann die TAN dazu dann in der Liste finden. Bei den Banken heißt das iTAN-Verfahren. Ist natürlich unbequem, weil B die Liste haben muß, aber rechnen Müssen ist auch unbequem. :)
Bei 4 stelliger TAN kann man einfach alle durchprobieren...
Jetzt Nicht schrieb: > Bei 4 stelliger TAN kann man einfach alle durchprobieren... Im Prinzip: ja Allerdings: wer stellt sich schon stundenlang hin und probiert im Sekundentakt alle 4 stelligen Zahlen durch. Vor allen Dingen dann, wenn nach jeder 3.ten -Falsch-Eingabe eine neue TAN gültig wird.
Dussel schrieb: > ein Computer alles, was man von Hand verschlüsseln kann, innerhalb > kurzer Zeit brechen kann, Das mit der 'kurzen Zeit' ist so eine Sache. Denn entweder man kennt das Berechnungsverfahren von vorne herein, oder aber man hat soviele Beispiele, um das Verfahren daraus ableiten zu können. Welche Beziehung besteht denn zwischen
1 | 4873 und 9674 |
bzw.
1 | 8539 und 4488 |
? Wenn das Gerät daher
1 | 2849 |
ausgibt, welches ist denn dann der dazu passende TAN? Selbst wenn du noch 10 weitere gültige Pärchen hättest, würde ich bezweifeln, dass du rauskriegst, wie ich die TAN bestimmt habe.
Jetzt Nicht schrieb: > Bei 4 stelliger TAN kann man einfach alle durchprobieren... TAN Listen funktionieren genau wie 4-stellige Bank-Pins nur deshalb, weil nach x Fehlversuchen das Laden dicht gemacht wird.
Was ist der Unterschied zu TLS? Du hast eine Zufallzahl als Schlüssel für eine Session. Den willst du asymetrisch verschlüsselt übertragen. Mit einem Schlüssel, den nur B kennt und einem anderen Schlüssel, den nur D kennt. Wie währe es mit einem TLS Verfahren, das zusätzlich von B freigegeben werden muss?
Das Stichwort hier ist nicht TAN sondern One Time Password (OTP). https://tools.ietf.org/html/rfc4226 https://tools.ietf.org/html/rfc6238 Wenn man das mit dem solitaire Algorithmus statt den üblichen Verdächtigen verwendet, geht es auch von Hand. https://www.schneier.com/solitaire.html
... genauer gesagt, nachdem G den Public-Key von D hat, entscheidet B, ob G das Handshake abbricht, oder seinen Public-Key an D sendet.
Ja, das kann man machen. Ist nicht besonders schwierig. Am einfachsten verwendest du eine bewährte und als schwer bekannte Einwegfunktion, z.B. eine der kryptographischen Hash-Funktionen aus dem SHA-2 Satz: http://de.wikipedia.org/wiki/SHA-2 Dann kannst du z.B. die Zufallszahl einfach an deinen Schlüssel anhängen und aus der entstehenden Zeichenkette den SHA-2 Hash ausrechnen. Den nimmst du dann modulo deiner geplanten TAN-Länge und erhälst eine recht schnell zu berechnende und damit auch schnell zu überprüfende Einweg-TAN. Natürlich darf dein Gerät nur ein paar Fehleingaben erlauben, bzw. muss so etwas wie sich verdoppelnde Wartezeiten verwenden, sonst hat man ja tatsächlich die Möglichkeit alle TANs durchzuprobieren. Um aber aus der TAN den Schlüssel zu gewinnen müsste man in der Lage sein, die Hashfunktion umzukehren. Das ist aber wirklich schwierig. Gäbe es jemanden der das sicher könnte, so wäre dieser bzw. in der Lage nach belieben neue Bitcoins zu generieren und damit recht schnell ziemlich reich zu werden.
Karl Heinz schrieb: > Allerdings: wer stellt sich schon stundenlang hin und probiert im >Sekundentakt alle 4 stelligen Zahlen durch. Wenn man es schafft, sekündlich eine TAN einzugeben, hätte man in unter 3 Stunden alle Möglichkeiten durch. Falls sich das automatisieren lässt (was bei Eingabe über PC in der Regel recht einfach ist), ist das nur eine Geduldsfrage. >wenn nach jeder 3.ten -Falsch-Eingabe eine neue TAN gültig wird. Dann dauerts halt drei mal so lange. Dafür gebe ich immer die gleiche TAN ein und warte, bis diese an der Reihe ist. Natürlich in der Hoffnung, dass auch tatsächlich alle Möglichkeiten dran kommen... @Dussel: Ich würde in diesem Fall dem Besitzer die Möglichkeit geben, einen Zweitzugang manuell zu konfigurieren. Dieser Schlüssel könnte x Minuten nach der ersten Verwendung (durch den Dritten) ablaufen. Somit könntest du dir die ganze Mathematik sparen bzw. die Aufgabe, einen sicheren Schlüssel festzulegen, an den Besitzer outsourcen ;-) Das ist aber natürlich keine Antwort auf die prinzipielle Frage. Ich gebe Nosnibor recht, dass das nicht so ganz einfach lösbar sein dürfte (sonst ist es auch leicht zu knacken). Falls es doch eine Lösung gibt, würde die mich aber auch interessieren^^
Die Vorschläge muss ich mir nochmal durchlesen und durchdenken. Brute-Force kann man bei sowas grundsätzlich erstmal immer anwenden. Rein praktisch könnte man das deutlich erschweren, weil B die TAN zuerst von Hand ausrechnen muss. Das heißt, D muss locker mindestens zehn Sekunden warten. Wenn man also nur alle zehn Sekunden eine Eingabe erlaubt, erschwert das die Sache schon deutlich. Das kann man natürlich beliebig weitertreiben, ist aber nur für die Praxis interessant. Hier geht es ja um die Theorie.
Jetzt Nicht schrieb: > Bei 4 stelliger TAN kann man einfach alle durchprobieren... Bei den TANs muss man sich ja nicht auf solche beschränken, welche nur auf vier Ziffern bestehen... S. E. schrieb: > Ja, das kann man machen. Ist nicht besonders schwierig. Am einfachsten > verwendest du eine bewährte und als schwer bekannte Einwegfunktion, z.B. > eine der kryptographischen Hash-Funktionen aus dem SHA-2 Satz: > http://de.wikipedia.org/wiki/SHA-2 > > Dann kannst du z.B. die Zufallszahl einfach an deinen Schlüssel anhängen > und aus der entstehenden Zeichenkette den SHA-2 Hash ausrechnen. Den > nimmst du dann modulo deiner geplanten TAN-Länge und erhälst eine recht > schnell zu berechnende und damit auch schnell zu überprüfende > Einweg-TAN. ich glaube nicht, dass dies (SHA) per Hand und Kopfrechnen noch praktikabel ist.
> Man bereitet eine Liste von zufällig gewählten TANs Das ist natürlich eine triviale Lösung. Aber wie du schreibst, muss man dafür die Liste immer dabeihaben. Nosnibor schrieb: > Schwierig. Einfache Rechenoperationen sind meist auch einfach umkehrbar. Das dachte ich auch, bis ich eben vom Doppelwürfel gehört habe. Bei dem Verfahren müssen so viele Informationen verlorengehen, dass es nicht mehr möglich ist, eindeutig den Schlüssel zu berechnen. Karl Heinz schrieb: > Denn entweder man kennt das Berechnungsverfahren von vorne herein, oder > aber man hat soviele Beispiele, um das Verfahren daraus ableiten zu > können. Die Sicherheit soll alleine durch die PIN (dem privaten Schlüssel) von B kommen. Das heißt, auch bei bekanntem Verfahren soll das Verfahren noch sicher sein. Noch einer schrieb: > Wie währe es mit einem TLS Verfahren, das zusätzlich von B freigegeben > werden muss? S. E. schrieb: > z.B. > eine der kryptographischen Hash-Funktionen aus dem SHA-2 Satz: TLS und SHA kenne ich nicht gut genug, um das beurteilen zu können, aber lassen die sich von Hand berechnen? Das ist ja gerade das Spannende an der Sache ;-) Andreas P. schrieb: > Ich würde in diesem Fall dem Besitzer die Möglichkeit geben, > einen Zweitzugang manuell zu konfigurieren. Dazu müsste B aber dauerhaft Zugriff auf G haben oder er müsste sich wieder mehrere Schlüssel merken.
> TLS und SHA kenne ich nicht gut genug, um das beurteilen zu können, aber > lassen die sich von Hand berechnen? Das ist ja gerade das Spannende an > der Sache ;-) mh, ja, sicher nicht in 10 Sekunden. Da wäre schon einiges mehr an Zeit fällig und man würde wahrscheinlich etwas mit kürzeren Hashes verwenden.
Dussel schrieb: Jetzt soll es aber > möglich sein, dass ein Dritter D das Gerät einmalig bedient, wenn B > nicht anwesend ist, ohne dass D den 'Hauptschlüssel' erfährt mit dem er > ständig Zugriff auf G hätte. > Von Ratschlägen solcher Weise raten wir hier ab im Forum, das könnte Verbrecher anspornen, das zu kriminellen Handlungen und Zwecken zu benutzen!! Lasst diesen Beitrag hier bitte verschwinden! Solche Fragestellungen sind auch im Internet unter Strafe gestellt! Wer das nicht glaubtm, möchte bitte einen Staatsanwalt oder Rechtsanwalt kontaktieren, oder gar die Kripo!! Also solche Themen gehören NICHT in ein solches Forum! Mit freundlichen Grüßen KOK unbenannt! - LKA Wiesbaden / Abteilung Internet-Kriminalität
Unbenannter KOK schrieb: > das könnte Verbrecher anspornen, das zu kriminellen Handlungen und > Zwecken zu benutzen!! Ist damit auch jede Art von Verschlüsselung verboten, weil sie von eben solchen Leuten genutzt werden kann? Es klingt zwar nachvollziehbar, jedoch ist das auf viele andere Dinge genau so zurück zu führen. Ich mein: Auf der einen Seite Sicherheit, auf der anderen Seite aber eben auch Sicherheit - nur eben positiv oder negativ eingesetzt, je nach Betrachter.
Hallo, ich denke, das geht auch einfacher. Man könnte z. Bsp. folgendes Verfahren verwenden: http://de.wikipedia.org/wiki/Keeloq
Wenn das Verschlüsselungsverfahren zu gut ist, legt D eben Hand an B an, um vollständigen Zugriff auf G zu bekommen.
Die Berechnung eines SHA-256 Hashes würde wohl mit der Hand etwa 1,5 Tage dauern: http://www.righto.com/2014/09/mining-bitcoin-with-pencil-and-paper.html Also schon noch irgendwie möglich, aber wohl für die Anwendung unpraktikabel. 10 Sekunden ist aber wahrscheinlich auch unrealistisch. Als Mensch kann man ja in 10 Sekunden wahrscheinlich nicht wirklich mehr als 10 Rechenoperationen machen. Der Computer kann diese dann ja genauso auch nachspielen und alle möglichen Schlüssel ausprobieren um eine Übereinstimmung zu finden. Damit das ganze trotzdem sicher ist, müsste also der Schlüssel extrem lang sein, damit der Rechner selbst beim ausprobieren von nur 10 Rechenoperationen noch überfordert ist. Mit sehr langen Schlüsseln kann man natürlich nur schwer in kurzer Zeit im Kopf rechnen. Also dürfte man immer nur Teile des langen Schlüssels verwenden, das geht dann fast schon wieder in die Richtung One-Time-Pad. Man müsste also nach einem praktikablen Mittelweg aus Schlüssellänge und Komplexität des Algorithmus suchen, der natürlich dann auch stark davon abhängt, wieviele TANs man vergeben möchte, d.h. welche Datengrundlage man einem eventuellen Knackalgorithmus bieten würde.
S. E. schrieb: > Der Computer kann diese dann ja genauso auch > nachspielen und alle möglichen Schlüssel ausprobieren um eine > Übereinstimmung zu finden. Stimmt. Manchmal sieht man den Wald vor lauter Bäumen nicht. Bei vierstelligen Zahlen könnte man mit einem Zufallszahl-TAN-Paar alle PINs ausprobieren und damit auf höchstens ein paar wenige einschränken. Daran habe ich wirklich nicht gedacht… Längere Zahlen machen es wieder schwieriger, von Hand zu rechnen. Als letzte Möglichkeit bliebe halt noch Buchstaben, Sonderzeichen und Zahlen anstatt nur Zahlen zu verwenden, also ein Passwort. Ich denke grundsätzlich wäre der Ansatz über eine Hashfunktion am Besten, wobei die PIN der Text und die Zufallszahl der Salt wäre. Gibt es eine Einweghashfunktion, die von Hand berechenbar ist?
Dussel schrieb: > Ich denke grundsätzlich wäre der Ansatz über eine Hashfunktion am > Besten, wobei die PIN der Text und die Zufallszahl der Salt wäre. Gibt > es eine Einweghashfunktion, die von Hand berechenbar ist? Das hilft auch nicht gegen das Argument der Schlüssellänge und des Durchprobierens. Der Angreifer hat mindestens ein Paar von Zufallszahl und passender TAN. Dann kann er sämtliche möglichen PINs (per Computer) durchprobieren. Wenn die PIN kurz ist, bekommt er wahrscheinlich nur einen Treffer und kennt damit die PIN. Wenn die PIN länger ist, wird er mehrere Treffer haben. Dann muß er an der Maschine ausprobieren, welche von mehreren möglichen PINS die richtige ist, oder sich bei Gelegenheit ein weiteres Zufallszahl-TAN-Paar verschaffen. Dagegen hilft nur, die PIN so lang zu machen, daß es zu lange dauern würde, alle Möglichkeiten am Computer durchzuprobieren. Aber dann kann B sich die lange PIN nicht mehr merken. Das Argument ist völlig unabhängig davon, mit welchem Verfahren aus Zufallszahl und PIN die TAN berechnet wird. Das einzige, was dagegen hilft, wäre ein Verfahren, das auf dem Computer spürbar lange dauert. Das kann dann aber auch B nur noch mit einem Computer benutzen.
Andreas P. schrieb: > Karl Heinz schrieb: >> Allerdings: wer stellt sich schon stundenlang hin und probiert im >>Sekundentakt alle 4 stelligen Zahlen durch. > > Wenn man es schafft, sekündlich eine TAN einzugeben, hätte man in unter > 3 Stunden alle Möglichkeiten durch. Falls sich das automatisieren lässt > (was bei Eingabe über PC in der Regel recht einfach ist), ist das nur > eine Geduldsfrage. ...da es sich um ein eigenständiges Gerät handelt kann man derartiges Ausprobieren wirksam unterbinden, etwa indem man es nach der dritten Falscheingabe für eine Stunde sperrt, einen besonderen Entsperrschlüssel anfordert (beim Handy üblich) oder eine Entsperrung nur durch den Hersteller/Systembetreiber möglich ist (EC-Karte)
...noch rustikalere Lösungen wie eine Selbstzerstörung sind theoretisch auch möglich, bei zivilen Anwendungen aber unüblich.
Unbenannter KOK schrieb: > Solche Fragestellungen > sind auch im Internet unter Strafe gestellt! > > Wer das nicht glaubtm, möchte bitte einen Staatsanwalt oder Rechtsanwalt > kontaktieren, oder gar die Kripo!! Also solche Themen gehören NICHT in > ein solches Forum! > > Mit freundlichen Grüßen > > KOK unbenannt! - LKA Wiesbaden Also dacht' er messerscharf: Nicht sein kann, was nicht sein darf! Wieviele Menschen hat diese dümmliche Einstellung von Bürokraten wohl schon auf's Schaffott (und das nicht nur im übertragenen Sinne) gebracht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.