Hallo, Danke für das Feedback! Ich hab mir mal ein paar Gedanken gemacht, wie sowas unter diesen Gegebenheiten in µC-gerechte Brocken zerlegt aussehen könnte:
Ich nenne mal die beiden Teilnehmerstationen "S1" und "S2". Beide haben den gleichen pre-shared Key, sagen wir mal 32bit lang, den sie schon zur Compilierzeit bekommen. Beide können eine hinreichend zufällige und einmalige Zahl, sagen wir mal 16bit lang, erzeugen (z.B. aus Einschaltdauer, Uhrzeit, Datum, etc.) ECMD-Befehle sind auf beiden generell nicht aktiviert! Wenn S1 jetzt einen Befehl an S2 schicken möchte könnte das so laufen: - S1 generiert eine Zufallszahl und sendet diese im Klartext an S2. - S2 speichert die Zahl, generiert selber eine Zufallszahl und schickt diese im Klartext an S1 zurück. Damit haben beide Stationen für die aktuelle Transaktion: - einen garantiert unverfälschten öffentlichen Schlüsselteil - einen empfangenen öffentlichen Schlüsselteil - den geheimen Pre-shared key. - S1 baut jetzt einen String zusammen, der die drei Schlüsselteile und den Befehl selbst enthält, und berechnet die MD5-Summe darüber - S1 sendet den Befehl selbst (im Klartext) und die MD5-Summe an S2 - S2 baut aus dem empfangenen Befehl und den eigenen drei Schlüsselteilen den gleichen String zusammen, berechnet die MD5, und vergleicht seine MD5 mit der empfangenen. - Sind die beiden MD5-Summen identisch, führt S2 den Befehl aus. - S2 sendet nach dem gleichen Schema ein Feedback zurück an S1, dass der Befehl ausgeführt wurde. Oder, wenn etwas nicht passte, eben eine entsprechende Fehlermeldung. - beide Stationen löschen ihre öffentlichen Schlüssel wieder. Ich denke da an einen kleinen Zustandsautomaten in C6. Das sollte sowohl gegen "Fremdfunker" wie auch Replay-Attacken helfen, hinreichend sicher sein, und einen Atmega nicht vor unlösbare Aufgaben stellen - oder? Ich freue mich über Meinungen dazu! :-) Die Fragen, die bleiben, und auf die ich keine Beispiele / Doku finden konnte, sind die folgenden: - Ethersex kann ja schon MD5. Nur wie ist mit der Funktion überhaupt umzugehen, wie ist der Aufruf? - Kann ich in C6 irgendwie direkt IP-Pakte (vermutl. UDP) direkt senden und empfangen, um an ECMD vorbeizukommen? Danke schon mal und viele Grüße, Nico -----Ursprüngliche Nachricht----- Von: dl4huf [mailto:dl4...@t-online.de] Gesendet: Dienstag, 12. März 2013 21:38 An: Nico Dziubek Betreff: Re: [ethersex-devel] Absicherung RFM12 Hallo Nico Deine Gedanken sind sicherlich richtig. Ich vermute das sich noch nicht viele solche Gedanken gemacht haben und eine verschlüsselte Übertragung sicherlich das Optimum darstellt. Es hat aber wohl noch keiner gemacht. Allerdings stellt sich mir die Frage wie groß die Angriffsfläche wirklich ist. Was spricht ein RFM12 für ein Protokoll ? Wie leicht kann man das Protokoll beim mitlesen ermitteln ? Das hängt sicherlich auch vom Traffic ab. Wenn da alle paar Stunden mal ein Packet versandt wird kann das dauern. Wie leicht erkennt man das es eine Ethersex-Verbindung ist und kann dann die Parameter wie IP-Bereich usw. ermitteln. Kann man ein einzelnes gesendetes Telegramm ( z.B. ein ECMD im UDP-Packet) einfach duplizieren, neu aussenden und wird das dann verarbeitet ? Wären dann TCP-Verbindungen besser um solche einfachen Angriffe abzuwehren ? Eine "einfache" Variante der Absicherung gegen das Ausführen von kritischen Befehlen wäre z.B. diese Befehle in Control6 zu implementieren und dort eine geeignete Authentifizierung einzubauen. Z.B. Absender-IP + GeheimWort + Zeitstempel + ECMD gehasht. oder ECMD mit einer Art Wechselcode (wie das die Autoschlüssel machen) gehasht. Das ist zwar alles nicht sicher, erschwert aber das abhören und erhöht die Schwelle für Einbrüche. Die normalen ECMDs kann man sicher deaktivieren. Für "kritischen" System wie Rollladen ist aber sicher auch eine Ausführungsquittung notwendig. Denn Funk kann leicht so gestört werden das gar keine Übertragung statt findet. In diesem Fall kann man fehlende Quittungen aber gut für Fehlermeldungen auswerten und unerwartete "Quittungen" für Alarmirrungen. Oder Du musst dich eben mit dem Quellcode auseinander setzten und die Interface-Bindung einbauen. Das abschalten der Standart-ECMDs und die Verwendung eigener Routinen in Control6 mit IP-Absender-Prüfung wäre auch eine erste Möglichkeit um VPN-only-Befehle zu machen. so .. das meine Gedanken zu dem Thema Gruß Ronald Am 12.03.2013 20:19, schrieb Nico Dziubek: > Hallo liebe Ethersex-Gemeinde, > > leider keine Antwort... ich versuch's nochmal mit einer einfacher > formulierten Frage ;-D > > Ich möchte gerne eine RFM12-Verbindung gegen "Fremdfunker" absichern, > insbesondere gegen die Ausführung von ECMD-Befehlen. Bei z.B. einer > Fenstersteuerung ganz sinnvoll, denke ich... :-) > > Der ECMD-Parser und das Esex-Webinterface reagiert aber an jeder IP > des Ethersex-Moduls. Daher die Frage - geht es,... > > - das Ethersex so zu konfigurieren, dass es ausschließlich nur noch > auf eine Verbindung über OpenVPN reagiert? Also die Befehle und das > Interface exklusiv an eine IP oder Schnittstelle zu binden? > - das RFM12-Interface so zu konfigurieren, dass es komplett (OpenVPN) > verschlüsselt ist und gar keine anderen Verbindungen akzeptiert? > - noch etwas ganz anderes zu machen, das das erfüllt? > > Danke und viele Grüße, > Nico > > > _______________________________________________ > Ethersex-devel mailing list > Ethersex-devel@list.zerties.org > https://list.zerties.org/cgi-bin/mailman/listinfo/ethersex-devel > _______________________________________________ Ethersex-devel mailing list Ethersex-devel@list.zerties.org https://list.zerties.org/cgi-bin/mailman/listinfo/ethersex-devel
