[HaBo]

xblax

Anzeige

Asymmetrische Verschlüsselungen werden allerdings in der Regel vor allem für digitale Signaturen verwendet. Das heißt, dass der Private und öffentliche Schlüssel für jede Sitzung identisch bleiben.

Idee ist, dass der öffentliche Schlüssel im Vorraus über eine andere (sichere) Verbindung ausgetauscht wird, bzw. die Authentizität durch einen 3. bestätigt wird. Das macht dann in der Theorie, vorrausgesetzt der öffentliche Schlüssel wurde einmal sicher übertragen eine Man in the Middle Attacke unmöglich.

Angenommen dein Verfahren wird bei einem Webserver (Alice) zur Verschlüsselung eingesetzt. Bob könnte also den privaten Schlüssel von Alice knacken um sich hinterher selbst als Alice auszugeben.

Darkslide

1. Die Sicherheit deines Verfahrens hängt also vom öffentlichen Schlüssel ab? Irgendwas stimmt da was nicht... du verletzt damit das Kerkhoffsche Prinzip, da der öffentliche Schlüssel eben öffentlich ist und die Sicherheit eines Verfahrens nur vom geheimen Parameter (bei asymm. Verfahren eben der private Key) abhängen sollte.

2. Ein Wechseln des öffentlichen Schlüssels ist bei asymmetrischen Verfahren nicht notwendig und auch nicht sinnvoll.

3. Wie willst du mit deinem Verfahren (Wechseln des öffentlichen Schlüssels) sinnvoll digitale Signaturen einsetzen?

Elderan

Hallo,
Echt? Das ging nirgends aus Paper hervor.

Der öffentliche Schlüssel und der private Schlüssel sollen also von Alice vor jeder neuen Sitzung neu generiert werden?

Falls ja: Wie möchtest du dann den sicheren Austausch des öffentlichen Schlüssels sicherstellen? Bob muss ja irgendwie den öffentlichen Schlüssel von Alice bekommen. Diesen kann Alice aber nicht simpel an Bob über eine unsichere Leitung senden, weil Eve dann eine Man-in-the-Middle Attacke durchführen könnte. Sie würde einfach den öffentlichen Schlüssel von Alice abfangen und durch ihren eigenen ersetzen. Bob würde dann seinen Sitzungsschlüssel mit Eves öffentlichen Schlüssel verschlüssel. Das würde Eve wieder abfangen, entschlüssel und dann den Sitzungsschlüssel korrekt verschlüsselt an Alice senden. Alice und Bob denken beide jeweils, dass sie miteinander kommuniziert hätten.

Um das zu verhindern müssen Alice und Bob vor jeder Sitzung eine Möglichkeit finden, auf sichere Weise den neu generierten öffentlichen Schlüssel auszutauschen. Dann könnten sie aber gleich den Sitzungsschlüssel austauschen.

Ich bin bei dem Angriff ausgegangen, dass Alice nur ein einziges mal ein Schlüsselpaar generiert und diesesn dann an alle verteilt, die mit ihr kommunzieren wollen, so wie es bei jedem anderen asymmetrischem System üblich ist. Dort könnte dann ein Angreifer wie oben beschrieben an Alice privaten Schlüssel gelangen.


Wie erwähnt. Erzeugt man vor jeder neuen Kommunikation ein Schlüsselpaar ist man bei dem Ausgangsproblem: Wie tausche ich diesen sicher aus?

zzador

Hallo,

Zu xblax: Ich versuche hier kein Verfahren zum erstellen von Digitalen Signaturen zu etablieren, sondern einen Weg, über eine unsichere Verbindung Daten auszutauschen, ohne dass man sich persönlich zum Zweck des Schlüsselaustausches treffen müsste. Der Diffie-Hellman-Key-Exchange besitzt z.B. auch keine Möglichkeit der Digitalen Signatur und ist Anfällig gegen Man-In-The-Middle-Angriffe. Auch RSA wurde nicht direkt für den Gebrauch als Digitale Signatur entwickelt. Diese Eigenschaft ein asymmetrisches Verfahren auch als Digitale Signatur nutzen zu können wurde jedesmal erst in Nachhinein erkannt und verwendet und hat mit dem eigentlichen Sinn einer asymmetrischen Verschlüsselung nur bedingt etwas zu tun.

Zu Darkslide: Nein, Du scheinst das Verfahren immer noch nicht verstanden zu haben. Der private Schlüssel besteht aus den Positionen der Paritäten im öffentlichen Schlüssel. Nehmen wir z.B. RSA. Der private Schlüssel besteht aus dem beiden Primfaktoren während der öffentliche Schlüssel das Produkt der Modulo-Multiplikation beider Primfaktoren ist. Bei meinem Verfahren besteht der öffentliche Schlüssel aus 2 grossen Matrizen, der private Schlüssel allerdings aus der Kenntniss welche Matrix markiert wurde, sowie über die Positionen der Paritäten in dieser Matrix. Der Wechsel des öffentlichen Schlüssels pro Sitzung soll nicht sinnvoll sein? Wie soll dass denn bitte zu begründen sein. RSA-Schlüssel werden nur selten neu generiert, da das generieren recht rechenaufwendig ist (Das rechnen mit 1024bit Dezimalzahlen dauert halt seine Zeit im Vergleich zu der Anzahl der Sitzungen die ein Server verwalten muss). Die Neugenerierung eines Schlüssels für jede Sitzung würde die Sicherheit allerdings drastisch erhören, dies sollte einem schon die Logik sagen. Halte ich immer den selben Schlüssel ist das wie ein fest stehendes Ziel und auf ein fest stehendes Ziel kann man sich eben gut "einschiessen". Nebenbei gesagt werden in vielen Bereichen gleich sehr viele öffentliche RSA-Schlüssel vorberechnet und diese dann zu bestimmten Zeitabschnitten verwendet. Eine Art Kompromiss zwischen Rechenlast und Sicherheit. Was die digitalen Signaturen angeht, so möchte ich hier auf meine Antwort zu xblax weiter oben verweisen.

Zu Elderan: Ja, ich hielt es für selbstverständlich das für jede Sitzung ein neuer öffentlicher Schlüssel generiert wird, da ich das Verwenden des selben Schlüssels für mehrere Sitzungen generell für unsicher halte, egal welches Verfahren verwendet wird. Den Grund für diese Ansicht findest du oben in der Antwort zu Darkslide's Post. Im Gegensatz zu RSA kann mit meinem Verfahren sehr viel schneller ein Schlüssel generiert werden, da wie bereits erwähnt keine großen Rechnungen durchgeführt, sondern lediglich ein sicherer Zufallsgenerator verwendet wird. Daher stellt die Rechenlast hier auch kein großes Problem dar, insbesondere nicht, wenn dass Verfahren, wie von mir geplant, zusammen mit einem symmetrischen Verfahren direkt in Silicium gebrannt wird. Was den Punkt des Man-In-The-Middle-Angriffs angeht: Ohne die erst später erkannte Möglichkeit des Signierens würde diesem Angriff auch heute noch kein Verfahren etwas entgegensetzen können. Ich werde mir die nächsten Tage mal Gedanken machen, ob ich mein Verfahren nicht auch irgendwie zum Signieren verwenden/abändern kann, jedoch möchte ich hier nochmal darauf hinweisen, dass ich hier keine Möglichkeit des digitalen Signierens beschreibe, sondern eine Möglichkeit über eine abgehörte Leitung sicher Daten auszutauschen (Das selbe Problem aus dem DHKE und RSA erwachsen sind).
Was Dein Statement angeht: Alice generiert öffentlichen Sitzungs-Schlüssel. Alice sendet diesen an Bob. Bob verschlüsselt damit den AES-Sitzungs-Schlüssel. Bob sendet diesen an Alice. Alice entschlüsselt diesen mit dem privaten Sitzungs-Schlüssel. 3 Schlüssel pro Sitzung. 1 privater Schlüssel, 1 öffentlicher Schlüssel und 1 AES-Schlüssel.

Zum Schluss dieser Post nochmal Danke an euch dass Ihr euch die Mühe macht die Schwachstellen aufzudecken.

Gruß,
Marc

Darkslide

Dann würde ich doch gerne von dir hören, warum die wiederholte Verwendung des öffentlichen Schlüssels unsicher sein soll bzw. warum das Wechseln des öffentlichen Schlüssels für jede neue Sitzung die Sicherheit eines Verfahrens (Nicht nur deines Verfahrens sondern allgemeiner Verfahren) erhöht. Und die Sicherheit deines Verfahrens hängt in dem Sinne sehr wohl von dem öffentlichen Schlüssel ab. Wenn wir Elderans Atacke nehmen, dann ist das wiederholte Verwenden des öffentlichen Schlüssels eine Schwachstelle deines Verfahrens. De facto kannst du also bei dem Verfahren den öffentlichen Schlüssel nicht für mehrere Sitzungen benutzen. Wie du schon sagtest ist JEDES asymmetrische Verfahren anfällig gegen MITM. Warum also bei DHKE erwähnen, dass es gegen MITM anfällig ist, wenn dein Verfahren ebenso dagegen anfällig ist?

Wo liegt das Problem, des ständigen Wechsel des öffentlichen Schlüssels?

"Hey Alice ich würde gerne mit dir einen AES Schlüssel austauschen." "Oh nein Charlie warte kurz, ich muss erst neue öffentliche Schlüssel erzeugen, da ich gerade mit Bob einen AES Schlüssel ausgetauscht habe."

Du darfst nicht nur in kleinen Dimensionen denken, dass 2 Leute einen Schlüssel austauschen wollen. Was ist mit Key Establishment in großen Firmen?Was ist mit Zertifikaten?Denkst du vielleicht, dass die Zertifizierungsstelle Lust hat jedes mal den öffentlichen Schlüssel auszutauschen?

Im Prinzip haben wir also ein Verfahren, welches:

- nicht geeignet ist den öffentlichen Schlüssel konstant zu halten
- nicht geeignet ist große Datenmengen zu verschlüsseln
- nicht geeignet ist Digitale Signaturen zu erzeugen
- Das 1000-fache des Inputs als Output generiert

Elderan

@zzador:
Ah okay, dann habe ich es nun verstanden. Dann wäre es sinnvoll dies nicht asymmetrische Verschlüsselung zu nennen, da dies nahe legt dass man das Schlüsselpaar einmalig geniert und dann fortlaufend nutzt (wie bei z.B. RSA).
Stattdessen beschreibst du ein Key-Exchange- bzw. Key-Establishment-Protokoll.

Das extreme Problem bei deinem Protokoll ist, das es meiner Meinung nach keine leichte Möglichkeit gibt, einen MITM Angriff zu verhindern bzw. die von Alice and Bob geschickten öffentlichen Schlüssel zu signieren, da sich dieser stets ändert.
Protokolle die nicht gegen MITM-Angriffe resistent sind, finden in der Praxis fast keine Anwendung. Auch das Diffie-Hellman Protkoll wird nur in einer Fassung verwendet, die es erlaubt einen MITM-Angriff auszuschließen. Und zwar indem Alice nicht jedes mal ein neues a wählt und g^a mod p rechnet, sondern einmalig g^a mod p berechnet, das Ergebnis sich von jemand fremdes signieren lässt und es dann zukünftig stets das gleiche, signierte Ergebnis an Bob sendet.

Da wie erwähnt ich nicht aktuell sehen kann wie man dein Verfahren gegen einen MITM Angriff absichern kann ohne den öffentlichen Schlüssel für Alice zu fixieren, sähe ich auch kein Einsatzgebiet für die Praxis.



Das stimmt, aber das ist nicht die Begründung warum dieser so selten neu generiert wird.

Nicht wirklich. RSA & Co. sind nach dem aktuell stand weiterhin sicher, auch wenn man den selben Schlüssel über Jahre nutzt. Dies zeichnet auch ein gutes Verschlüsselungsverfahren aus, dass man den Key eben nicht ständig wechseln muss. Die große Gefahr ist, dass der private Schlüssel gestohlen wird. Deswegen sollte muss man einen Trade-Off finden wie oft man diesen wechselt im Vergleich zu den Kosten diesen neu signieren zu lassen.
Aber für jeden neu generierten Schlüssel braucht man eine neue Signatur für den Schlüssel von einer externen Partei (einer CA). Dies macht es extrem ineffizient für jede neue Sitzung einen neuen Schlüssel zu generieren.

In der sicheren Kommunikation heutzutage läuft nichts mehr ohne Zertifikate ab. Unternehmen geben dafür Unsummen aus und beschäftigen eigene Abteilungen, nur um die Zertifikatsinfrastruktur zu managen.

Der Ablauf ist wie folgt:
Der Server erzeugt ein RSA-Schlüsselpaar (oder was auch immer man nutzen möchte) und sendet den öffentlichen Schlüssel per sicheren Kanal an eine Certificate Authority (CA) wie z.B. VeriSign. Diese CA signiert dann den öffentlichen RSA-Schlüssel und bestätigt damit, dass der RSA-Schlüssel zu einem bestimmten Server gehört, z.B. von einer Bank.
Der Server sendet dann später an seine Clients das Zertifikat, bestehend aus dem eigenen öffentlichen Schlüssel, der eigenen Identität (Bank XYZ) und der Unterschrift der CA.
Der Client hat zumeist vorab die entsprechenden Zertifikate der CAs installiert (wird bei Windows, Linux, MacOS direkt bei der Installation mit ausgeliefert) und kann so überprüfen, ob die CA wirklich die Identität des Servers überprüft hat und ob der öffentliche Schlüssel zum Server gehört.

Die Schlüssel werden so selten gewechselt (für gewöhnlich alle 1 bis 2 Jahre), da die Identitätsfeststellung durch die CA recht aufwendig und auch recht teuer ist. Wie gesagt, große Unternehmen beschäftigen eigene Abteilungen die sich nur um bald auslaufende Zertifikate kümmern und dass diese rechtzeitig erneuert werden.

---------------------


Zwar ist die Grundidee sehr nett, für die Praxis aber leider nicht wirklich zu gebrauchen. Wie bereits oft erwähnt, lassen sich MITM Angriffe nicht ausschließen. Aber selbst wenn man das gar nicht fordert, ist das große Problem die großen Datenmengen.

Die beiden Matrizen (256x1024 Bits) haben eine Größe von zusammen 64KB. Da wie erwähnt die Datenübertragung der langsamste Schritt ist, hätte die CPU schon längst die Operationen für Diffie-Hellman berechnet während man bei deinem Verfahren noch bei der Übertragung der Daten ist.

Weitere Probleme wäre, dass sich die Entschlüsselung nicht effizient auf aktuellen CPUs realisieren lässt, da man nur umständlich die Parität berechnen kann. Die Erweiterungs des Instruction Sets der CPU wäre also von nöten. Bis aber CPU-Hersteller kryptographische Funktionen in ihre CPUs verdrahten, vergeht Jahre bis Jahrzehnte.

Ebenso muss man jedes mal neu mehr als 64KB an zufälligen Daten erzeugen (die Matrizen+Subsets), und zwar auf eine sichere Art und Weise. Da ist dann die Frage, ob man die Erzeugung der 64KB Zufallsdaten schneller hinbekommt als z.B. die Entschlüsselung bei RSA bzw. die Berechnungen bei Diffie-Hellman.

Nutzt man Skein-512 zur Erzeugung von kryptographisch sicheren Zufallsdaten (einer der schnellsten kryptographisch sicheren Zufallsgeneratoren), so muss man ca. 7 Cylces/Byte an Rechenzeit aufwenden. Bei 64Kb wären dies bereits ca. 470 000 CPU-Cycles, nur zur Erzeugung der beiden Martizen notwendig sind.

Ein vollständiger Key-Exchange mittels elliptischen Kurven und Diffie-Hellman braucht laut eBATs nur ca. 200 000 bis 250 000 CPU-Cycles.


Auch wenn die involvierten Operationen sehr simpel sind, braucht die zufällige Erzeugung der Matrizen unglaublich viel Zeit, was sich auch nicht wirklich reduzieren lässt.

zzador

Vielleicht wäre es wirklich besser, den ganzen Thread in "Ein Verfahren für den abhörsicheren Austausch eines Schlüssels" umzunennen. Zumindest dürfte das dann hier so einige bzgl. der Thematik "Signierung und Zertifikate" beruhigen . Die Hauptintention meines Verfahrens ist wie bereits erwähnt die realisierung direkt in Hardware um z.B. 2 Chips auf einer Platine sicher miteinander kommunizieren zu lassen. Das Beispiel mit dem Server, habe ich lediglich als Vergleich zu RSA herangezogen. Wie bereits erwähnt hat asymmetrische Verschlüsselung nur bedingt etwas mit Zertifikaten zu tun. Zertifikate gehören in die Sparte "Digitale Signatur" und das ist etwas anderes, als asymmetrische Verschlüsselung, auch wenn RSA als Paradebeispiel hierfür genutzt werden kann. Eine nackte asymmetrische Verschlüsselung muss lediglich über eine abgehörte Datenleitung sicheren Datensaustausch ermöglichen. Verfahren zum Vermeiden eines MITM wurde erst später entwickelt (Digitale Signatur) und setzten IMHO praktisch nur auf der asym. Verschlüsselung auf. Was Deinen (Elderan) Einwand der Paritätsprüfung auf heutigen CPUs angeht bzgl. der fehlenden Instruktionen...also ich teste meine Paritäten im Beispiel per XOR und XOR ist verdammt schnell auf meiner CPU. Mir ging es bei diesem Thread hauptsächlich darum mögliche Schwächen am Verfahren selbst aufzudecken und nicht, ob es dies und das nicht beherrscht. Daher möchte ich hier besonders Elderan nochmal danken, der sich die Mühe gemacht hat einen Ciphertext-Angriff zu entwickeln für den Fall, dass ein öffentlicher Schlüssel für mehrere Sitzungen verwendet wird. Auch Danke an alle die sich einfach mal so mit dem Verfahren beschäftigt haben, auch wenn sie vll. nicht die Zeit oder die Lust hatten eine echte Schwachstelle zu suchen.

PS.: Was den Wechsel des RSA Schlüssels für jede Sitzung angeht: Die Primfaktorzerlegung ist zwar langsam bei grossen Decimalzahlen, jedoch gibt es zu diesem Zweck mittlerweile auch Spezialhardware, die zu erstaunlichen Leisstungen in der Lage sind. Sicher dauert die Zerlegung eines 2048 Bit-Schlüssels damit immernoch seine Zeit, doch wenn ich für jede Sitzung einen neuen Schlüssel generiere, kann man sich das Zerlegen gleich ganz sparen. Klar ist ein 2048 Bit Schlüssel sicher genug um über mehrere Jahre hinweg benutzt zu werden. Dennoch ist die Neu-Generierung des Schlüssels für jede Sitzung sicherer da der Angreifer mit seiner Zerlegung damit ja bei jeder Sitzung neu anfangen darf.

Gruß,
Marc

Elderan

Um die Parität einer n-stelligen Untersumme mittels Shiften&XOR zu überprüfen, braucht man mind. 2n+[Anzahl Datenwörter] CPU-Cycles bei einer normalen, modernen CPU. Da die Untersummen an variablen Stellen sind, sogar wohl noch deutlich mehr.

Durch eine entsprechende Logik in der CPU könnte man diesen Aufwand aber auf 2 CPU-Cycles pro Datenwort reduzieren.

Das meinte ich mit vergleichsweise langsam

Ansonsten würde mich natürlich mal ein Software-Benchmark von dem System interessieren, da es in der Tat sehr simpel ist und für low price Prozessoren durchaus geeignet sein könnte. Dort ist aber die Frage ob die mit 2x32kb großen Matrizen umgehen können oder ob man lieber ein normales Rechenwerk für modulare Arithmethik mit integieren sollte. Fragen über Fragen


Ansonsten wenn der öffentlich Key nur ein einziges mal genutzt wird und wir von einem perfekten Random Oracle ausgehen zur Erzeugung aller Zufallsdaten, dürfte das System soweit sicher sein.

zzador

Hallo nochmal,

In den letzten Tagen habe ich nochmal die Zeit gefunden über eure Beschwerden bzgl. des Aufblähens des Ciphertextes nachzudenken. An dieser stelle möchte ich daher darauf hinweisen, dass das Verfahren die Möglichkeit bietet dieses Aufblähen zu reduzieren, allerdings nur, indem der öffentliche Schlüssel vergrößert wird. Benutze ich als öffentlichen Schlüssel nich 2x32kb Matrizen, sondern statt dessen 256x32kb Matrizen so ist man in der Lage direkt ein Byte (8 Bit) auf einmal zu verschlüsseln. Dadurch würde der Ciphertext nicht mehr um den Faktor 1024 sondern um den Faktor ( 1024 / 8 ) = 128 aufgebläht. Der öffentliche Schlüssel würde damit dann allerdings 8 MB groß werden. Man könnte aufgrund der Tatsache, dass man nun 256 anstatt 2 Matrizen verwendet, ggf. die Sicherheits-Parameter der Matrizen reduzieren (z.B 512x256 anstatt 1024x256) und so die Grösse des öffentlichen Schlüssels und der Ciphertext-Nachrichten noch weiter reduzieren. Um eine generelle Vergrösserung des Ciphertextes wird man aber nicht herum kommen.

PS.: Durch diese Variante dürfte der von Elderan vorgeschlagene Ciphertext-Angriff auch erschwert werden.

Gruß,
Marc