Hallo alle! Ich streite mich gerade mit meinem Chef über das Thema Abhörsicherheit von WLAN und ISM-Modulen, die AES Encoding an Board haben (z.B. ZWAVE, XBEE). Wenn man mit den Modulen immer gleiche Befehle sendet, ist es denn möglich, diese abzufangen und einfach neu zu senden? Also quasi die abgefangen Pakete einfach nochmal senden, um damit dann die entsprechende Funktion hinter dem gesendeten Kommando auszulösen? Ich habe irgendwie Zweifel dran, dass das so einfach gehen soll, dann wäre ja die Welt in noch größerem Chaos, oder? Eine Anwendung wäre hier ein Toröffner mittels ESP8266 (verbudnen über lokales WLAN) bzw das gleiche nur mit ZWAVE oder XBEE. Wird bei WLAN nicht auch ein Zeitstempel oder irgendwas mitgesendet bzw in der Verschlüsselung benutzt, oder lieg ich da komplett falsch? PS: hat eventuell jemand Infos zu ZWAVE (z.B. ZM5304AU) und wie die angesprochen werden? Scheinbar muss man erst ein DEVKIT kaufen, damit man Unterlagen bekommt ... Danke für Antworten :)
Nik A. schrieb: > Wenn man mit den Modulen immer gleiche Befehle sendet, ist es denn > möglich, diese abzufangen und einfach neu zu senden? wenn man es richtig macht dann nicht. Für weiter Infos siehe: https://en.wikipedia.org/wiki/Replay_attack eine reine AES Verschlüsselung, erzeugt jedes mal die gleichen verschlüsselten Daten, ist damit also anfällig für so etwas. Wenn aber über WLAN TCP übertragen wird, hat man dann schon eine nutzt dagegen. (bei UDP nicht)
Es kommt halt auf das Protokoll drauf an, wie die Verschlüsselung genutzt wird. Man kann es sicher designen oder unsicher. Nur einfach AES über die Daten zu jagen bringt rein garnichts (replay attacks). Normalerweise nutzt man dynamische Session Keys und nutzt ein nonce etc im Datenblock, Counter usw. Im Endeffekt muss man sich hier jedes Protokoll einzeln angucken. Einen absoluten Standard gibt es nicht. Generell kannst du davon ausgehen, dass WLAN sicherer ist als der Teils proprietäre Müll..
Ah, okay, das klärt schon mal etwas auf :) Danke! Unsere Lösung wäre die Generierung eines temporären Schlüsses für das jeweilig anstehende Paket, quasi als Handshake zwischen beiden Geräten. Ich hatte nur gedacht, bei WLAN wäre das durch eventuelle Protokoll-Features (hab davon keine Ahnung) schon automatisch gelöst, wenn man sich über WPA2 etc mit dem AP verbindet, und dieser Handshake somit "überflüssig" in der Firmware der jeweiligen Devices.
Nik A. schrieb: > Unsere Lösung wäre die Generierung eines temporären Schlüsses für das > jeweilig anstehende Paket, quasi als Handshake zwischen beiden Geräten. und was ist wenn ein Paket nicht ankommt, bzw. die Bestätigung nicht ankommt? Das ganze kann sehr kniffelig werden. > Ich hatte nur gedacht, bei WLAN wäre das durch eventuelle > Protokoll-Features (hab davon keine Ahnung) schon automatisch gelöst, kann durchaus sein, aber die Frage ist ob das auf den Layer hingehört.
wenn ein Paket nicht ankommt, gibt's 'nen Timeout Wie es genau softwareseitig aktuell gelöst wird, kann ich nicht sagen, die Programmierung macht ein anderer Ich habe lediglich nach sicheren (und günstigen) Alternativen zum RFM12B gesucht, der uns sporadisch ein paar Probleme bereitet.
usuru schrieb: > Von Microchip gibt es KeeLoq, alles drin. Das ist der Schrott der schon lange theoretisch geknackt wurde und auch wenig später in der Praxis ausgenutzt wurde.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.