Ist dieses Szenario sicher?

Question

Ich bin mit RSA Kommunikation zwischen einem Server zu verschlüsseln und zu einem Client. Lassen Sie uns sagen wir 2 Asymmetrische Schlüssel haben, die Taste 1 und key2.

Der Server verfügt über key1 (Private) von Anfang an und der Kunde hat die key1 (öffentlich)

So, hier ist das Szenario:

1. der Client generiert key2
2. Client eine Verbindung zum Server
3. Senden key2 (öffentlich) verschlüsselt mit key1 (public)
4. ab sofort auf dem Server werden alle Daten mit dem key2 (public)
verschlüsselt senden
5. sendet der Client einige zufällige Daten an den Server
6. sendet der Server die gleichen Daten gehasht
zurück
7. prüft der Kunde, dass die Daten richtig

Soweit ich sehen kann dies einen Man-in-the-Middle-Angriff verhindern soll, oder bin ich etwas fehlt? Bei Punkt 7 der Client sollte wissen, ob jemand versucht, den Server den falschen Schlüssel zu geben, mit zu verschlüsseln, wie niemand sonst, aber der Server kann key2 (öffentlich) entschlüsseln.

Wenn es etwas gibt, was getan werden kann, um die Sicherheit sagen Sie mir bitte zu verbessern.

Answer 1

Das Beste, was Sie tun können, um die Sicherheit zu verbessern, ist ein bestehendes Design zu verwenden und nicht versuchen, das Rad neu zu erfinden. Ich sage nicht, dass das, was Sie getan haben, unbedingt falsch ist, sondern nur, dass viele Menschen viel klüger als du und ich haben viel Zeit, sich Gedanken über dieses Problem verbrachte. TLS verwenden statt.

Answer 2

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

Ich glaube, ich das irgendwo sah tatsächlich in einem Papier. Darin gab Alice Bob eine unverschlossene Box (Taste 1 public), dann Bob ein paar seiner eigenen Kartons (Taste 2 public) darin, sperrt sie und sendet sie an Alice zurück. Alice öffnet dann die Box (Taste 1 privat), und jetzt kann sie sicher die Boxen abdichten, die Bob gab ihr nur.

Trotz der Box Analogie, das ist im Wesentlichen, was Sie tun, so würde ich seine sichere sagen.

Answer 3

Ich bin damit einverstanden, nur TLS verwenden.

Auch welchen Wert Sie die Schritte 5 bis 7 zur Verfügung stellen? Ein MITM will einen Angriff zu tun, die nach den Schritten 1-4 (indem n Transaktionen durch und dann stoppt zum Beispiel DoS von einer Art, eine Wiederholung von Anfang an gezwungen) funktionieren würden tun könnte so einfach wie auch nach 5-7. Was tragen sie?

- MarkusQ

Answer 4

Nein, das Protokoll ist nicht sicher.

Ein Mann-in-the-middle können die Daten durch den Client gesendet abfangen und senden, was sie an den Server will, da man keinen Mechanismus für den Server angegeben haben, den Client oder überprüfen Sie die Integrität von Nachrichten zu authentifizieren erhält.

Natürlich könnten Sie Ihren Arzt auf Ihr Protokoll diese eklatanten Probleme zu beheben, aber es würden andere sein. Wenn Sie jemals sie alle beheben, würden Sie etwas haben, das TLS oder SSH-Karten, also warum nicht einfach da anfangen?

---

@ Petoj-das Problem war ich mit Schwerpunkt auf war, dass der Server die Nachrichten zu vertrauen es empfängt; Ihr Vorschlag bietet keine Sicherheit gibt. Allerdings, wenn Sie sich Sorgen um die Vertraulichkeit, Sie immer noch ein Problem haben, weil die MITM-Nachrichten passieren könnte zurück und her unverändert, bis er sieht, was da Sie auf den Client-Nachrichten keine Privatsphäre haben nicht finden will.

Ihr Vorschlag scheint auf die Gewährleistung der Integrität von Nachrichten vom Client angestrebt werden. Sie haben das Protokoll zu dem Punkt entwickelt, wo der Kunde zwischen einem Angriff und einem Netzwerkausfall nicht unterscheiden kann. Anstatt zu versuchen, die Client zu bestimmen, ob der Server auf einer manipulierten Nachricht, damit der Server die Integrität der Nachricht zu überprüfen, bevor Sie handeln auf mich gehandelt zu helfen.

Answer 5

Ich werde mit Greg zustimmen, dass Sie das Rad neu erfinden . Was Sie im Wesentlichen beschreiben einige grundlegende Form von Schlüsselaustausch . Übrigens, um sicherzustellen, dass es sicher ist gegen Man-in-the-Middle-Angriffe müssen Sie auch die Identität des Servers sicher sein, dh sicherzustellen, dass der Kunde mit Sicherheit wissen können, dass das, was er glaubt, öffentlich zu sein (key1) wirklich ist die Server und nicht das Mann-in-the-middle ist (zB ein CA mit oder dem Server öffentlichen (key1) in sicherer Lagerung auf der Client-Seite.)

Darüber hinaus gibt es weitere Überlegungen Sie müssen von einem System Standpunkt darüber im Klaren sein, wie zum Beispiel:

• asymmetrische Key-Verschlüsselung ist langsamer als symmetrische Schlüssel-Verschlüsselung, die einer der Gründe, warum bestehende Lösungen wie TLS wird asymmetrische Schlüssel-Verschlüsselung verwendet nur einen temporären symmetrischen Schlüssel zu verhandeln, die dann für die Kanalverschlüsselung verwendet wird.
• , wenn die Verkehrsanalyse von einem Dritt gelingt einen temporären symmetrischen Schlüssel in Cracken, Sie haben Sie asymmetrisches Schlüsselpaar nicht beeinträchtigt wird. Sie sind ermutigt der temporäre Schlüssel neu zu verhandeln relativ oft aus diesem Grund. Sicherlich wäre mildert diesen Aspekt ein neues key2 in Ihrem Szenario zu erzeugen.