Alle Schwachstellen in Ihrem Protokoll können als "SSL verwenden" oder sogar "SSL verwenden, verdammt!" zusammengefasst werden.

Weitere Informationen:

• Das gesamte Protokoll ist natürlich anfällig für Identitätswechsel, insbesondere für den doppelten Identitätswechsel, der auch als Man-in-the-Middle-Angriff bezeichnet wird.
• Ebenso, wenn einer der potenziellen Angreifer dies tut kann lauschen auf der Linie beschließt, eine Änderung der Daten während der Übertragung vorzunehmen, dann kann er, und Ihr Client und Server werden nicht klüger sein.
• Die Erfahrung zeigt, dass " Alle Daten mit diesem Schlüssel verschlüsseln "und dann richtig zu machen, ist furchtbar komplex. SSL selbst hat fast 15 Jahre dafür gebraucht, und viele Implementierungen sind immer noch nicht in der Lage. Auffüllen von Orakeln, vorhersehbare IV, MAC-Überprüfungszeitpunkt, verifizierter Abschluss, Schutz vor erneuter Sequenzierung und Wiedergabe von Paketen ...

Als Gesamtbewertung: Tun Sie das nicht.

Nein, dieses Protokoll ist nicht sicher.

Wie bereits in den Kommentaren erwähnt:

Rollen Sie keine eigene Krypto. Wahrscheinlich verstehen Sie es falsch. Besonders wenn Sie zugeben, dass Sie nicht wirklich wissen, was Sie tun.

Erstens scheinen Sie Standardprobleme zu haben, für die es bereits Standardprotokolle gibt, die nette Eigenschaften und Sicherheitsnachweise haben . Das Protokoll für die Datenübertragung sollte TLS v1.2 (oder neuer) sein. Sie sollten hierfür eine Bibliothek verwenden (wie NSS, GnuTLS oder OpenSSL). Für die Kennwortauthentifizierung verwenden Sie am besten SRP oder TLS-SRP. Wenn Sie sich SRP jedoch wirklich nicht leisten können (was Ihre erste Wahl sein sollte), können Sie trotzdem diesem Dokument folgen.
Bisher für die Verbesserungen.

Nun zum Fehler Ihres Protokolls:

1. Es ist anfällig für Man-in-the-Middle-Angriffe. Wenn sich ein Angreifer zwischen dem Gerät und dem Server befindet, kann er den öffentlichen Schlüssel fischen und durch seinen eigenen ersetzen. Als Antwort würde er den AES-Schlüssel kennen und alle Daten entschlüsseln können.
2. Sie erwähnen nicht die Integrität / Authentizität der Daten. Es hört sich so an, als ob Sie den EZB-Modus für AES verwenden möchten (den Sie wirklich nicht verwenden möchten ). Mit AES wären Sie viel besser dran -GCM für die Massenverschlüsselung. Sie erwähnen auch nicht, wie RSA verwendet werden soll. RSA-OAEP sollte Ihre Wahl sein (und nicht Lehrbuch-RSA). Ich gehe jedoch davon aus, dass Sie dies mit Ihrer Implementierung getan hätten.
3. Sie haben das Gerät sehr stark belastet. Das Gerät muss bei jeder Verbindung einen neuen privaten RSA-Schlüssel generieren, was eine sehr rechenintensive Aufgabe ist. Sie sollten lieber die Verwendung des ECDH-Schlüsselaustauschs in Betracht ziehen.
4. Damit die Überprüfung der Kennwörter funktioniert, muss der Server die Kennwörter entweder im Klartext speichern oder selbst hashen, um DoS-Angriffe auf den Server zu ermöglichen. Und falls ein Man-in-the-Middle-Angriff stattfindet, werden die einfachen Passwörter einem Angreifer angezeigt, was Ihren Benutzern ernsthaften Schaden zufügen kann (da sie ihre Passwörter möglicherweise standortübergreifend wiederverwenden ...)
ol>

Das Gerät generiert einen privaten RSA-Schlüssel und sendet den öffentlichen Schlüssel an den Server.

1. Der Server generiert einen eindeutigen AES-Schlüssel für den Benutzer und verwendet den Öffentlicher RSA-Schlüssel zum Verschlüsseln und Zurücksenden an das Gerät.

2. Das Gerät erhält den AES-Schlüssel. Verwendet es zum Verschlüsseln von Kennwort und Benutzername und sendet es an den Server.

ol>

Anonymer Schlüsselaustausch.

Es erfolgt keine Authentifizierung. Ihr Schlüsselaustausch ist verschlüsselt, aber nicht authentifiziert. Das ist schlecht.

Wenn es einen aktiven Mann in der Mitte gibt, haben Sie keine Möglichkeit, dies zu erkennen. Dieser aktive MitM kann dem Client nur so tun, als sei er der Server. Und tun Sie dem Server gegenüber so, als sei er der Client.

-> Tun Sie es nicht. @ SEJPM stimmt mit seinem Kommentar überein. Verwenden Sie etablierte Kryptosysteme. Wie TLS mit Zertifikaten oder TLS mit SRP.

Auf diese Weise verwende ich eine RSA / AES-Kombination.

1. Client generiert einen zufälligen AES-Schlüssel.
2. Verwenden Sie den AES-Schlüssel, um die benötigten Daten zu verschlüsseln (RSA Take) längere Zeit und Längenbeschränkung, verwenden Sie also besser aes zum Verschlüsseln.)
3. Verwenden Sie den öffentlichen Schlüssel zum Verschlüsseln des aes-Schlüssels.
4. Übergeben Sie die verschlüsselten Daten und den von rsa public verschlüsselten aes-Schlüssel Schlüssel zum Server
5. Wenn der Server empfängt, entschlüsseln Sie diesen AES-Schlüssel mit einem privaten Schlüssel und entschlüsseln Sie dann die angehängten Daten mit dem entschlüsselten AES-Schlüssel

Es ist ziemlich gut, aber ich würde dies auf eine einfachere Art und Weise tun, die meiner Meinung nach sicherer und ähnlicher ist als die, an die Sie gedacht haben.

Da die Kommunikation Client-Server ist:

1. Mobiler Client generiert Schlüssel mit PRNG
2. Client sendet Schlüssel für Schritt 1 mit öffentlichem Serverschlüssel (nur Server muss privat entschlüsselt werden)
3. Client verschlüsselt Benutzer / Kennwort mit Schlüssel für Schritt 1 und sendet an Server
4. Wenn Benutzer / Passwort überprüft wurden, gibt der Server einen neuen Schlüssel für die Datenverschlüsselung zurück, der mit dem Schlüssel von Schritt 1
ol>

- verschlüsselt ist. Bitte führen Sie Schritt 2 - 4 über TLS aus, wenn möglich

-. Ändern Sie die Schlüssel alle X-Iterationen (auf Client und Server erzwingen)

---. Der Client muss dem Serverzertifikat vertrauen, um MITM / Identitätswechsel

zu verhindern