Ist dieses Szenario sicher?

Solange key1 (privat) nicht von einem Drittanbieter abgefangen wurde, sieht Ihr Szenario sicher aus.

Ich glaube, ich habe das irgendwo in einer Zeitung gesehen. Darin gab Alice Bob eine unverschlossene Schachtel (Schlüssel 1 öffentlich), dann steckte Bob ein paar seiner eigenen Boxen (Schlüssel 2 öffentlich) hinein, sperrte sie ein und schickte sie zurück zu Alice. Alice öffnet dann die Box (Schlüssel 1 privat) und jetzt kann sie die Boxen, die Bob ihr gerade gegeben hat, sicher verschließen.

Trotz der Box-Analogie, das ist im Wesentlichen, was Sie tun, also würde ich sagen, es ist sicher.

Ich stimme zu, verwenden Sie einfach TLS.

Welchen Wert bieten auch die Schritte 5 bis 7? Ein MITM, der einen Angriff ausführen möchte, der nach den Schritten 1-4 funktioniert (z. B. DoS, indem er n Transaktionen durchleitet und dann stoppt, erzwingt einen erneuten Versuch von Anfang an), könnte dies genauso gut nach 5-7 tun. Was fügen sie hinzu?

- MarkusQ

Nein, dieses Protokoll ist nicht sicher.

Ein Man-in-the-Middle kann die vom Client gesendeten Daten abfangen und die gewünschten Daten an den Server senden, da Sie für den Server keinen Mechanismus zur Authentifizierung des Clients oder zur Überprüfung der Integrität der Nachrichten angegeben haben empfängt.

Sicher, Sie könnten Ihr Protokoll aufarbeiten, um diese eklatanten Probleme zu beheben, aber es würde andere geben. Wenn Sie jemals alle beheben, haben Sie etwas, das TLS oder SSH zugeordnet ist, also warum nicht einfach dort anfangen?

@ Petoj - das Problem, auf das ich mich konzentrierte, war, dass der Server den empfangenen Nachrichten vertraute; Ihr Vorschlag bietet dort keine Sicherheit. Wenn Sie jedoch Bedenken hinsichtlich der Vertraulichkeit haben, haben Sie immer noch ein Problem, weil das MITM Nachrichten unverändert hin und her weiterleiten kann, bis er sieht, was zu finden ist, weil Sie keine Privatsphäre auf den Client-Nachrichten haben.

Ihr Vorschlag scheint darauf ausgerichtet zu sein, die Integrität von Nachrichten vom Client sicherzustellen. Sie haben das Protokoll so weit entwickelt, dass der Client nicht zwischen einem Angriff und einem Netzwerkausfall unterscheiden kann. Statt zu versuchen, dem Client zu helfen, festzustellen, ob der Server auf eine manipulierte Nachricht reagiert hat, lassen Sie den Server die Integrität der Nachricht überprüfen, bevor Sie darauf reagieren.

Ich stimme Greg zu, dass Sie das Rad neu erfinden . Was Sie im Wesentlichen beschreiben, ist eine grundlegende Form des Schlüsselaustausches . Um sicherzugehen, dass es gegen Man-in-the-Middle-Angriffe sicher ist, müssen Sie sich außerdem der Identität des Servers sicher sein, dh sicherstellen, dass der Client mit Sicherheit weiß, was er für öffentlich hält (key1) der Server und nicht der Man-in-the-Middle-Server (z. B. eine CA verwenden oder das Public (key1) des Servers im sicheren Speicher auf der Clientseite haben).

Außerdem gibt es zusätzliche Überlegungen , die Sie vom Standpunkt des Systems aus kennen müssen, wie zum Beispiel:

• Die asymmetrische Schlüsselverschlüsselung ist langsamer als die symmetrische Schlüsselverschlüsselung. Dies ist einer der Gründe, warum bestehende Lösungen wie TLS verwendet die asymmetrische Schlüsselverschlüsselung nur, um einen temporären symmetrischen Schlüssel auszuhandeln, der dann für die Kanalverschlüsselung verwendet wird.
• Wenn die Analyse des Datenverkehrs durch einen Drittanbieter erfolgreich einen temporären symmetrischen Schlüssel knackt, haben Sie Ihr asymmetrisches Schlüsselpaar nicht kompromittiert. Sie werden aus diesem Grund dazu ermutigt, den temporären Schlüssel relativ oft neu zu verhandeln. Wenn Sie in Ihrem Szenario ein neues key2 generieren, wird dies möglicherweise gemildert.