Welche Garagentor Automatiken gelten inzwischen durch hacking als unsicher?
Nano schrieb: > Welche Garagentor Automatiken gelten inzwischen durch hacking als > unsicher? Alle.... Old-Papa
Old P. schrieb: > Nano schrieb: >> Welche Garagentor Automatiken gelten inzwischen durch hacking als >> unsicher? > > Alle.... > > Old-Papa Dann sag mir mal, wie du ohne Besitz des Schlüssels ein Garagentor öffnest, dass ein aktuelles asymmetrisches kryptographischen Schlüsselverfahren verwendet?
Nano schrieb: > dass ein aktuelles asymmetrisches kryptographischen > Schlüsselverfahren verwendet? Welches soll das sein?
Challenge Response mit aes265 zum Beispiel
Nano schrieb: > Dann sag mir mal, wie du ohne Besitz des Schlüssels ein Garagentor > öffnest, dass ein aktuelles asymmetrisches kryptographischen > Schlüsselverfahren verwendet? Im Zweifel genauso wie man ein KfZ mit Keyless Entry öffnet obwohl der Schlüssel im Wohnzimmer liegt ... Ich kann mir nicht vorstellen das Garagentorhersteller da cleverer Vorgehen als Autohersteller :)
Chris K. schrieb: > Challenge Response mit aes265 zum Beispiel Dann möge man mir einen Garagentorantrieb mitteilen der ein solches aktuelles Verfahren auch nutzt :) Die Auswahl dürfte... dürftig sein.
alopecosa schrieb: > Chris K. schrieb: > Challenge Response mit aes265 zum Beispiel > > Dann möge man mir einen Garagentorantrieb mitteilen der ein solches > aktuelles Verfahren auch nutzt :) > Die Auswahl dürfte... dürftig sein. Und bei dem nicht der Default Schlüssel "0000000000000000" verwendet wird, wie bei manchen Automobil Herstellern 😂
:
Bearbeitet durch User
Seit mir mal in einem Firmenwagen (VW Passat) an einer Bahnschranke die Türschlösser anfingen zu klappern (Stifte an der Tür gingen hoch und runter), glaube ich nicht an irgendein sicheres elektronische Schloss im Kfz. Sektor.
Meinst Du jetzt eine Liste mit Marken und Modellnamen oder mit Adressen, wo sie verbaut sind ? :-)) Sorry, couldn't ressist.
Liste? Jetzt neu auf Youtube "15 unglaubliche unsichere automatische Garagentore die man gesehen haben muss". Wenn der Einbrecher ein bisschen old-school ist, dann verschwendet er keine Zeit mit dem Knacken der Fernsteuerung sonder widmet sich kurz dem für den Notfall gedachten Schlüsselschalter. Die Zylinder in den Dingern sind mindestens genauso schlecht wie die in klassischen Garagentoren, wenn nicht sogar schlechter. Sollte der Zylinder ausnahmsweise relativ sicher sein dann ist es der Rest des Schlüsselschalters meist nicht. Dann wird der ganze Schalter von/aus der Wand gehebelt um an die Kontakte zu kommen. Sabotagekontakte, wenn überhaupt vorhanden, sind sowieso nur seltenst angeschlossen.
Nano schrieb: > Old P. schrieb: >> Nano schrieb: >>> Welche Garagentor Automatiken gelten inzwischen durch hacking als >>> unsicher? >> >> Alle.... >> >> Old-Papa > > Dann sag mir mal, wie du ohne Besitz des Schlüssels ein Garagentor > öffnest, dass ein aktuelles asymmetrisches kryptographischen > Schlüsselverfahren verwendet? Über die Notentriegelung, oder einen 2ten Zugang zur Garage.
Nano schrieb: > Dann sag mir mal, wie du ohne Besitz des Schlüssels ein Garagentor > öffnest, dass ein aktuelles asymmetrisches kryptographischen > Schlüsselverfahren verwendet? Schlüsselschalter an der Garagenwand ausbauen, die zwei Kontakte zusammenhalten, fertig ;)
alopecosa schrieb: > Im Zweifel genauso wie man ein KfZ mit Keyless Entry öffnet obwohl der > Schlüssel im Wohnzimmer liegt ... Erstaunlicherweise sind Garagentore da besser, weil sie auf einen Knopfdruck warten und nicht darauf, dass ein Transponder in Reichweite kommt.
Hannes J. schrieb: > Liste? Jetzt neu auf Youtube "15 unglaubliche unsichere automatische > Garagentore die man gesehen haben muss". Gibt einen schönen Kanal (LockPickingLawyer): https://www.youtube.com/watch?v=d-hBDjYtE1U
Jörg S. schrieb: > an der Garagenwand ausbauen, die zwei Kontakte Viel zu umständlich und langsam. Verbindung herstellen über Stechkontakte am Kabel.
Hannes J. schrieb: > Liste? Jetzt neu auf Youtube "15 unglaubliche unsichere automatische > Garagentore die man gesehen haben muss". > > Wenn der Einbrecher ein bisschen old-school ist, dann verschwendet er > keine Zeit mit dem Knacken der Fernsteuerung sonder widmet sich kurz dem > für den Notfall gedachten Schlüsselschalter. Du hast überhaupt nicht die Tragweite der unsicheren automatischen Garagentore begriffen. Das sind keine einzelnen Einbrecher, die gezielt mit Gewalt in ein bestimmtes Haus einbrechen wollen, sondern das sind organisierte Banden die mit dem Auto und ihrem eingeschalteten Hackinggerät auf gut Glück die Straßen abfahren und dann einfach darauf achten, ob irgendwo ein Garagentor aufgeht. Ist das der Fall, dann wissen sie, in welche Garage sie reinkommen. Und mit so einem Gerät ist man in wenigen Sekunden drin. Da muss man keine Gewalt anwenden und kommt auch in verhältnismäßig sichere Häuser rein, weil die unsichere Elektronik des Garagentor vom Hausherr als Unsicherheit nicht bedacht oder erkannt wurde. > Die Zylinder in den Dingern > sind mindestens genauso schlecht wie die in klassischen Garagentoren, > wenn nicht sogar schlechter. Mag sein, aber manche Elektronik ist noch viel unsicherer und sie hinterlässt keine Spuren. Der Betroffene merkt den Einbruch vielleicht nicht einmal oder nicht sofort, wenn die anliegende Wohnung, falls in der Garage ein Durchgang zur Wohnung besteht, mit Bedacht geräumt wird oder die Versicherung zahlt nicht, weil keine Einbruchspuren vorhanden sind.
Jörg R. schrieb: > Nano schrieb: >> Old P. schrieb: >>> Nano schrieb: >>>> Welche Garagentor Automatiken gelten inzwischen durch hacking als >>>> unsicher? >>> >>> Alle.... >>> >>> Old-Papa >> >> Dann sag mir mal, wie du ohne Besitz des Schlüssels ein Garagentor >> öffnest, dass ein aktuelles asymmetrisches kryptographischen >> Schlüsselverfahren verwendet? > > Über die Notentriegelung, oder einen 2ten Zugang zur Garage. Es geht hier um die Elektronik, nicht um irgendwelchen mechanischen Einbruch.
Nunja, Garagentor und sichere Elektronik sind ja schon alleine dadurch ein gewisser Gegensatz, dass die Lebenserwartung eines Garagentors durchaus nicht unter 20-30 Jahre anzusetzen ist. In der Zeit ist es recht wahrscheinlich, dass eine einst sichere Verschlüsselung ohne weiteres geknackt werden kann.
Ich schrieb: > Nunja, Garagentor und sichere Elektronik sind ja schon alleine > dadurch > ein gewisser Gegensatz, dass die Lebenserwartung eines Garagentors > durchaus nicht unter 20-30 Jahre anzusetzen ist. > In der Zeit ist es recht wahrscheinlich, dass eine einst sichere > Verschlüsselung ohne weiteres geknackt werden kann. Eben und deswegen gehe ich mal davon aus, dass es irgendwo ne Liste anfälliger Geräte geben müsste. Aber ich finde keine.
Ich schrieb: > Nunja, Garagentor und sichere Elektronik sind ja schon alleine dadurch > ein gewisser Gegensatz, dass die Lebenserwartung eines Garagentors > durchaus nicht unter 20-30 Jahre anzusetzen ist. > In der Zeit ist es recht wahrscheinlich, dass eine einst sichere > Verschlüsselung ohne weiteres geknackt werden kann. Allerdings nur bei bahnbrechenden mathematischen Erkenntnissen. Eine Challenge-Response-Authentifizierung mit AES256 wäre auch 20 Jahre nach Einbau sehr sicher. Traurig ist es allerdings wirklich, dass es offenbar keinen Hersteller gibt, der das mal vernünftig umsetzt. Wäre das nicht ein gutes Projekt hier für's Forum? Ich bin doch sicher nicht der einzige, der das Problem hat, dass es die alten Fernbedienungen nicht mehr gibt und die außerdem viel zu klobig sind.
Nano schrieb: > Eben und deswegen gehe ich mal davon aus, dass es irgendwo ne Liste > anfälliger Geräte geben müsste. Aber ich finde keine. Du betrachtest es immer noch von der falschen Seite. Gehe davon aus, dass fast alle unsicher sind und suche nach der sehr sehr kurzen Liste mit Geräten, die sicher sind. Dann musst du natürlich noch untersuchen, wer diese Geräte mit welcher Begründung für sicher hält.
Sicheres Garagentor: RPi mit WLAN und Relais in die Garage. Zum Öffnen mit dem Auto vorfahren, mit dem WLAN verbinden, mit SSH und geheimen Schlüssel (z.B. via Handy) beim RPi anmelden, Skript zum Toröffnen ausführen. Bei mehreren Nutzern einfach verschiedene Schlüssel in die authorized_keys eintragen. Statt WLAN funktioniert vielleicht auch Bluetooth.
Chris D. schrieb: > Traurig ist es allerdings wirklich, dass es offenbar keinen Hersteller > gibt, der das mal vernünftig umsetzt. Das ist nicht traurig, sondern teuer. Niemand ist bereit den Preis dafür zu zahlen. Vor allem, wenn der Nutzen eher bescheiden ist.
Ben Gunn schrieb: > Sicheres Garagentor: > > RPi mit WLAN und Relais in die Garage. Zum Öffnen mit dem Auto > vorfahren, mit dem WLAN verbinden, mit SSH und geheimen Schlüssel (z.B. > via Handy) beim RPi anmelden, Skript zum Toröffnen ausführen. Bei > mehreren Nutzern einfach verschiedene Schlüssel in die authorized_keys > eintragen. > > Statt WLAN funktioniert vielleicht auch Bluetooth. Ja, an so etwas hatte ich auch schon gedacht. Aber erstmal müsste ich wissen, ob Handlungsbedarf besteht. Also mein Garagentor unsicher ist. Geht man den Weg als nächsten Schritt, müsste man aber noch nachprüfen, ob die Funkeinheit vom Rest der Garagentorschaltung getrennt ist. Denn wenn sie das nicht ist, würde das bedeuten, dass man die ganze Garagentorelektronik nachbauen müsste und das ist dann Haftungstechnisch wieder ein zu heißes Eisen. Denn man stelle sich vor, das Garagentor geht zu, während jemand dabei eingeklemmt wird und die Elektronik stoppt den Motor nicht.... Da kauft man dann lieber von einem Hersteller eine neue und diesmal sicherere Elektronik. Gesetzt den Fall, der Markt bietet diese an.
mh schrieb: > Chris D. schrieb: >> Traurig ist es allerdings wirklich, dass es offenbar keinen Hersteller >> gibt, der das mal vernünftig umsetzt. > > Das ist nicht traurig, sondern teuer. Niemand ist bereit den Preis dafür > zu zahlen. Vor allem, wenn der Nutzen eher bescheiden ist. Was ist an einem modernen Mikrocontroller, auf dem man ein ordentliches kryptografisches Schlüsselverfahren umsetzen könnte, teuer?
Ich habe mal folgendes Video gefunden, da erzählt jemand, wie man grob einen Anhaltspunkt bekommt, ob das eigene Tor unsicher ist: https://www.youtube.com/watch?v=xcUpg-qAJ74 Allerdings richtet sich das an den US Markt. Es wäre denkbar, dass das bei uns anders ist. Die Lösung mit Dipschalter hat meine Torelektronik zum Glück nicht, diese Variante kann ich also schonmal ausschließen.
Nano schrieb: > Aber erstmal müsste ich wissen, ob Handlungsbedarf besteht. Also mein > Garagentor unsicher ist. Anscheinend hast du die mehrfachen Hinweise hier im Thread immer noch nicht gelesen: JEDES GARAGENTOR IST UNSICHER. GRUNDSÄTZLICH JEDES. IMMER. Ausnahmen sind nur nachweislich sichere Tore ... Oliver
Hörmann Bisecure, zwar nur aes128, aber immerhin seit einigen Jahren mit individuellen Code für jede Anlage.
So, ich habe mir jetzt mal die Webseite des Herstellers angeschaut. Seine neuste Technologie ist ein 128 Bit Verschlüsselungsverfahren wie beim Online Banking und zusätzlich ein Rolling Code Verfahren und er wirbt damit, dass nur den hausinternen Ingenieuren mitgeteilt wird, wie das Verfahren genau funktioniert. D.h. im Klartext, das Verfahren ist unsicher, denn gute Kryptografieverfahren basieren darauf, dass man das Verschlüsselungsverfahren veröffentlichen kann, ohne dass es dadurch unsicher wird. Also der typische Fehler von Security by Obscurity. https://www.marantec.com/de/unser-versprechen/sicherheit.html Bleibt lediglich zu hoffen, dass das verwendete Online Banking ähnliche Verschlüsselungsfahren, dass der Hersteller als solches bewirbt, aber leider nicht das eigentliche Kryptoverfahren dahinter angibt, wenigstens ein sicheres ist.
Nano schrieb: > mh schrieb: >> Chris D. schrieb: >>> Traurig ist es allerdings wirklich, dass es offenbar keinen Hersteller >>> gibt, der das mal vernünftig umsetzt. >> >> Das ist nicht traurig, sondern teuer. Niemand ist bereit den Preis dafür >> zu zahlen. Vor allem, wenn der Nutzen eher bescheiden ist. > > Was ist an einem modernen Mikrocontroller, auf dem man ein ordentliches > kryptografisches Schlüsselverfahren umsetzen könnte, teuer? Der Mikrocontroller ist nicht das Problem. Die Entwicklung der Software die darauf laufen soll schon. Hast du schonmal etwas entwickelt, das wirklich sicher ist?
Ich schrieb: > Nunja, Garagentor und sichere Elektronik sind ja schon alleine dadurch > ein gewisser Gegensatz, dass die Lebenserwartung eines Garagentors > durchaus nicht unter 20-30 Jahre anzusetzen ist. > In der Zeit ist es recht wahrscheinlich, dass eine einst sichere > Verschlüsselung ohne weiteres geknackt werden kann. Naja, da sind ja schon mit Hausmitteln für den induviduellen Bastler paar Varianten denkbar: Am einfachsten wäre es wohl, das gesamte Tor-Antriebssystem nur dann bestromen zu können, wenn es sinnvoll ist. Wenn die Garage besetzt ist, dann keine Fernöffnung von aussen möglich, da System stromlos - einschaltbar mittels (Schlüssel)-Schalter im Innenraum (bliebe dann die Frage, ob es irgendeine Vorschrift gäbe, die eine Notöffnungsmöglichkeit fordert, weiß ich gerade nicht). Falls Garage unbesetzt (also Nutzer will einfahren) muss zuerst (mittels FB o.ä)der Strom für das Torsystem eingeschaltet werden, um dann ganz normal mit der Tor-FB das Tor öffnen zu können. Sozusagen eine Zweifaktor-Toröffnung. Die müsste ja nicht unbedingt händisch bedient werden müssen.
MeierKurt schrieb: > ob es irgendeine Vorschrift gäbe, die eine Notöffnungsmöglichkeit > fordert, weiß ich gerade nicht). Für Deine simple Einzelgarage vorm Haus nicht, da die von der Feuerwehr einfach mit der Brechstange zu öffnen wäre. Aber für Tiefgaragen in Siedlungen und Wohnblocks ist das anders.
Nano schrieb: > D.h. im Klartext, das Verfahren ist unsicher, denn gute > Kryptografieverfahren basieren darauf, dass man das > Verschlüsselungsverfahren veröffentlichen kann, ohne dass es dadurch > unsicher wird. > Also der typische Fehler von Security by Obscurity. Wenn man zusätzlich zum guten Kryptographieverfahren ein Änderung einbaut und die Änderung verraten wird, dann landet man immer noch beim guten Kryptografieverfahren. Beispiel man verwendet 2 Verschlüsselungsverfahren nacheinander (das eine Team weiß vom anderen nichts) und zum Schluss kommt jemand der dass zusammenführt. Dann ist für mich die Sicherheit erstmal höher, und nur weil vielleicht rauskommt, dass da 2 Verfahren nacheinander durchgeführt wurden ist es deswegen nicht unsicher als nur Variante 1 Muss weg bin auf der Suche nach einer neuen Primzahl ;-)
mh schrieb: > Der Mikrocontroller ist nicht das Problem. Die Entwicklung der Software > die darauf laufen soll schon. Hast du schonmal etwas entwickelt, das > wirklich sicher ist? Also bezüglich Kryptografie gibt es bewährte Bibliotheken, manche auch Open Source, die man hier verwenden könnte. Und für µC ohne OS gibt es auch welche, die man lizenzieren kann, da es Firmen gibt, die sich darauf spezialisert haben. Die kosten dann Lizenzkosten und kann man in den eigenen Code einbetten.
Nano schrieb: > mh schrieb: >> Der Mikrocontroller ist nicht das Problem. Die Entwicklung der Software >> die darauf laufen soll schon. Hast du schonmal etwas entwickelt, das >> wirklich sicher ist? > > Also bezüglich Kryptografie gibt es bewährte Bibliotheken, manche auch > Open Source, die man hier verwenden könnte. > Und für µC ohne OS gibt es auch welche, die man lizenzieren kann, da es > Firmen gibt, die sich darauf spezialisert haben. Die kosten dann > Lizenzkosten und kann man in den eigenen Code einbetten. Dann ist diese Bibliothek sicher, dein System aber noch nicht. Oder nimmt dir diese Bibliothek jede Entscheidung ab, was und wie genau übertragen wird und wie auf Fehler bei der Übertragung reagiert wird.
Bisecure wurde schon gehackt https://futurezone.at/digital-life/hacker-zeigen-luecken-bei-tor-funksteuerung-auf/303.157.187
Nano schrieb: > manche auch Open Source, die man hier verwenden könnte. Natürlich ginge das und wäre besser als was es auf dem Markt gibt, wäre sogar ganz primitiv mit ATtiny13 zu realisieren. Aber dann wären Ersatzgeräte und Zusatzschlüssel sehr günstig zu bekommen. Das ganze ginge sogar auch noch ohne Besuch des Hersteller-/Firmentechnikers, wenn einer die Sache in die Hand nehmen würde.
Statistisch überwiegt die Anzahl der Leute, die glauben ein absolut sicheres Schloss entwickeln zu können, der Anzahl vorhandenen weitgehend sicherer Schlösser enorm. Theoretiker sind eben intelligenter als Praktiker, die das nur noch umsetzen sollen/müssten.
Ben Gunn schrieb: > Sicheres Garagentor: > > RPi mit WLAN und Relais in die Garage. Ich habe mir jetzt das noch einmal genauer angesehen. Die Motorsteuerung des Tores verfügt über zwei Pins über die auch Universalempfänger angeschlossen werden können. Die zwei Pins muss man mit einem Relais verbinden und wenn man dann das Relais mit bspw. einem Raspberry Pi schaltet, öffnet oder schließt das Tor abwechselnd. Im Prinzip also eine einfache Sache. Die Motorsteuerung muss hierbei nicht angerührt werden. Die Betriebssicherheit bleibt somit erhalten. Im Prinzip muss man also nur zusehen, dass der AP des Raspberry Pi oder falls der Raspi selber ein AP ist, schon von weitem erreichbar ist. Dann würde, sobald man sich mit dem Auto dem Haus nähert, das Handy sich mit dem AP automatisch verbinden und bis man dann da ist, steht die WLAN Verbindung dann schon, so dass man nur noch darüber ein Signal an den Raspi senden muss, dass dann das Tor öffnet. Sicher wäre das. Der einzige Haken ist der lange Verbindungsaufbau und die begrenzte Reichweite von WLAN. Das gilt insbesondere dann, wenn der AP z.b. in der Garage steht und das Signal dann dadurch gedämpft wird. > Zum Öffnen mit dem Auto > vorfahren, mit dem WLAN verbinden, mit SSH und geheimen Schlüssel (z.B. > via Handy) beim RPi anmelden, Skript zum Toröffnen ausführen. Du kannst auch auf den Raspberri Pi einen Webserver laufen lassen und dann per HTTPS und einer Weboberfläche das Tor schalten. Das funktioniert dann auch mit Geräte, die keinen SSH Client, aber zumindest einen Browser haben.
> Eben und deswegen gehe ich mal davon aus, dass es irgendwo ne Liste > anfälliger Geräte geben müsste. Aber ich finde keine. Erste Frage die sich ein Suchender stellen muß: - wer könnte so eine Liste erstellt haben? - und warum? - dann genau dort suchen (was nicht unbedingt Internet heißt sondern auch Telefon & E-Mail einschließt) Aber: nur weil man selbst eine fertige Liste sucht und meint dass es sie geben müßte, heißt das noch lange nicht, dass sie jemand schon erstellt hat. Und einfach nur gut versteckt hat... Natürlich gibt es zu allen möglichen Themen fertige Listen. Weil sie jemand erstellt hat der sich davon Reputation verspricht (oder Werbeeinnahmen).
Thomas O. schrieb: > Wenn man zusätzlich zum guten Kryptographieverfahren ein Änderung > einbaut und die Änderung verraten wird, dann landet man immer noch beim > guten Kryptografieverfahren. Falsch, da die häufigsten Probleme Implementierungsfehler sind. Was bringt AES, wenn der Key vorhersagbar ist? Was bringt WLAN mit WPA2, wenn das Defaultpasswort aus der MAC-Adresse berechnet werden kann (so geschehen bei diversen Herstellern)?
Nikolaus S. schrieb: >> Eben und deswegen gehe ich mal davon aus, dass es irgendwo ne > Liste >> anfälliger Geräte geben müsste. Aber ich finde keine. > > Erste Frage die sich ein Suchender stellen muß: > - wer könnte so eine Liste erstellt haben? > - und warum? > - dann genau dort suchen (was nicht unbedingt Internet heißt sondern > auch Telefon & E-Mail einschließt) > > Aber: nur weil man selbst eine fertige Liste sucht und meint dass es sie > geben müßte, heißt das noch lange nicht, dass sie jemand schon erstellt > hat. Und einfach nur gut versteckt hat... > > Natürlich gibt es zu allen möglichen Themen fertige Listen. Weil sie > jemand erstellt hat der sich davon Reputation verspricht (oder > Werbeeinnahmen). Also im PC Bereich geben seriöse Hersteller ihre CVE Sicherheitslücken auf ihrer Webseite bekannt, dann kann man da, wenn man ein betroffenes Produkt hat, nachgucken. Die CVE Einträgen landen dann auch in den großen CVE Datenbanken. Und die Defekte von Garagentorherstellen gehören so eigentlich auch kommuniziert, aber das ist wohl noch ne alte Branche, die nicht weiß, wie so etwas heutzutage gemacht wird.
Ralf X. schrieb: > Theoretiker sind eben intelligenter als Praktiker, die das nur noch > umsetzen sollen/müssten. Der Praktiker muss es für den Mainstream der Nutzer und Wartungspersonal umsetzen. Die Konkurrenz auf dem Markt muss er auch noch im Auge behalten. Der Theoretiker braucht es natürlich nur für seine eigene Garage umzusetzen. Alle anderen Fallvarianten können ihm da egal sein. Wenn dieser seine benötigten Mannstunden ansetzt und sich ansieht wieviel Mehrfaches an Mannstunden die Hersteller könnten, würde das reichen für die Erweiterung auf viele andere Fallvarianten.
Nano schrieb: > Welche Garagentor Automatiken gelten inzwischen durch hacking als > unsicher? Hallo Nano, Suchst du eigentlich für dein eigenes Garagentor eine sichere Lösung, oder interessiert dich das im Allgemeinen?
Nano schrieb: > Ben Gunn schrieb: >> Sicheres Garagentor: >> >> RPi mit WLAN und Relais in die Garage. > > Ich habe mir jetzt das noch einmal genauer angesehen. ... > Der einzige Haken ist der lange Verbindungsaufbau und die begrenzte > Reichweite von WLAN. Das gilt insbesondere dann, wenn der AP z.b. in der > Garage steht und das Signal dann dadurch gedämpft wird. Ich würde es als Feature erachten, wenn das WLAN nur sichtbar ist, wenn man nach davor steht. Das Spektrum ist eh schon zugemüllt. >> Zum Öffnen mit dem Auto >> vorfahren, mit dem WLAN verbinden, mit SSH und geheimen Schlüssel (z.B. >> via Handy) beim RPi anmelden, Skript zum Toröffnen ausführen. > > Du kannst auch auf den Raspberri Pi einen Webserver laufen lassen und > dann per HTTPS und einer Weboberfläche das Tor schalten. > > Das funktioniert dann auch mit Geräte, die keinen SSH Client, aber > zumindest einen Browser haben. Ich verstehe dich da evtl miss. Aber mMn wäre es so wie du schreibst Mist. Du willst ja nicht sicherstellen, dass du dich beim richtigen RPi/Webserver anmeldest, sondern dich gegenüber dem RPi authentifizieren. Wenn schon TLS, dann bräuchtest du hier ein (self-signed) Client Zertifikat. Ehrlich gesagt, finde ich SSH hier viel einfacher. Einen Toröffner-User anlegen, Toröffner-Skript als login-shell setzen. authorized_keys. Analog zum schließen. Fertig (sofern dir niemand die SD Karte aus der Garage klaut).
Ben Gunn schrieb: > (sofern dir niemand die SD Karte aus der > Garage klaut). Die kann man ja auch noch verschlüsseln.
Nano schrieb: > das sind organisierte Banden > die mit dem Auto und ihrem eingeschalteten Hackinggerät auf gut Glück > die Straßen abfahren und dann einfach darauf achten, ob irgendwo ein > Garagentor aufgeht. Ich persönlich glaube da nicht dran. Es mag noch ältere Tore aus den 70/80er geben, die durch einfachste Funksignale zu öffnen sind. Aber bei einem modernen Tor mit AES o.ä.? Überlege doch mal: Im Vorbeifahren werden mal eben so zilliarden Kombinationen in wenigen Sekunden gesendet oder der zufällig generierte Code zum Zeitpunkt x passt mal gerade so zum Tor an dem man vorbeifährt?
Nano schrieb: > Also im PC Bereich geben seriöse Hersteller ihre CVE Sicherheitslücken > auf ihrer Webseite bekannt, dann kann man da, wenn man ein betroffenes > Produkt hat, nachgucken. > Die CVE Einträgen landen dann auch in den großen CVE Datenbanken. > > Und die Defekte von Garagentorherstellen gehören so eigentlich auch > kommuniziert, aber das ist wohl noch ne alte Branche, die nicht weiß, > wie so etwas heutzutage gemacht wird. PC != Garagentorsteuerung mit dem billigsten verfuegbaren uC. Updatemoeglichkeit? Wurde gestrichen, der Steckverbinder war zu teuer ......... wendelsberg
wendelsberg schrieb: > PC != Garagentorsteuerung mit dem billigsten verfuegbaren uC. > Updatemoeglichkeit? Wurde gestrichen, der Steckverbinder war zu teuer > ......... Ich dachte moderne Garagentoröffner kommunizieren mit einer Cloud um Daten zusammeln und um (kaputte) Updates zu verteilen.
Wenn Du sichergehen willst bau Dir was Eigenes auf. Nichts ist so hackingsicher sicher wie eine individuelle Anlage, denn die Angriffe richten sich IMMER gegen kommerzielle Lösungen, die in Massen hergestellt werden. Jaja, Ich weiß, kann trotzdem alles sein wenn x und y zusammenkommen, aber irgendwo muss man ja auch mal eine Grenze ziehen.
Harald schrieb: > Nano schrieb: >> das sind organisierte Banden >> die mit dem Auto und ihrem eingeschalteten Hackinggerät auf gut Glück >> die Straßen abfahren und dann einfach darauf achten, ob irgendwo ein >> Garagentor aufgeht. > > Ich persönlich glaube da nicht dran. Es mag noch ältere Tore aus den > 70/80er geben, die durch einfachste Funksignale zu öffnen sind. Aber bei > einem modernen Tor mit AES o.ä.? Überlege doch mal: Im Vorbeifahren > werden mal eben so zilliarden Kombinationen in wenigen Sekunden gesendet > oder der zufällig generierte Code zum Zeitpunkt x passt mal gerade so > zum Tor an dem man vorbeifährt? Wer sagt, dass man die Verschlüsselung mit einem Brute-force Angriff knacken muss? Wenn das so wäre, wäre es sehr einfach so ein Schloss zu bauen. Es gibt noch andere Angriffe gegen die man sich schützen muss, z.B. ein Replay-Angriff oder ein anderer aus der Man-in-the "Gruppe". Was ist mit einem Denial-of-Service-Angriff, wenn du das Tor schließen willst? Du fährst weg, drückst auf die Fernbedienung und das Tor schließt sich nicht.
Nano schrieb: > Die Motorsteuerung des Tores verfügt über zwei Pins über die auch > Universalempfänger angeschlossen werden können. Das ist zwar richtig, dass an die beiden Pins ein beliebig sicherer Fernsteuer-Mechanismus angeschlossen werden kann - aber wenn der Torantrieb ab Werk einen unsicheren Funkempfänger eingebaut haben sollte, dann bleibt der unsicher, auch wenn du selbst ihn gar nicht nutzt - die postulierten Panzerknacker-Banden könnten ihn dann trotzdem anfunken. Wenn der Funkempfänger NICHT eingebaut ist, dann ergibt das Konzept Sinn, sonst eher nicht.
Harald schrieb: > einem modernen Tor mit AES o.ä.? Überlege doch mal: Im Vorbeifahren > werden mal eben so zilliarden Kombinationen in wenigen Sekunden gesendet > oder der zufällig generierte Code zum Zeitpunkt x passt mal gerade so > zum Tor an dem man vorbeifährt? Das ist die Theorie. Wie das in der Praxis umgesetzt wird, steht schon weiter oben Beitrag "Re: Gibts's irgendwo ne Liste mit unsicheren automatischen Garagentoren?" Oliver
Matthias L. schrieb: > Wenn der Funkempfänger NICHT eingebaut ist, dann ergibt das Konzept > Sinn, sonst eher nicht. Abgesehen von den beschrieben logischen Einbrüchen könnte auch eine Rauschattacke oder ein ausreichend starkes ISM-Signal schon das Schließen des Tores einfach verhindern? Dann nützt auch das schönste AES wenig. Weiterhin wäre zu klären, wenn "sichere" Zertifikate eingesetzt würden, wie lange diese funktionieren. Sicher nie 100 Jahre wie manche Garage steht!
mh schrieb: > Du fährst weg, drückst auf die Fernbedienung und das Tor > schließt sich nicht. Wenn man darauf nicht achtet halte ich einen „Einbruch“ für reiflich verdient. Nennt die Versicherung auch grobe Fahrlässigkeit. mh schrieb: > Wer sagt, dass man die Verschlüsselung mit einem Brute-force Angriff > knacken muss? Wenn das so wäre, wäre es sehr einfach so ein Schloss zu > bauen. Es gibt noch andere Angriffe gegen die man sich schützen muss, > z.B. ein Replay-Angriff oder ein anderer aus der Man-in-the "Gruppe". Gibt es da irgendwelche Berichte, dass das schon mal so gemacht wurde? Ich habe davon noch nichts gehört. Die ganzen Boulevard-Magazine würden darüber doch wie bekloppt berichten. Vielleicht ist es mir auch entgangen.
Thomas K. schrieb: > Nano schrieb: >> Welche Garagentor Automatiken gelten inzwischen durch hacking als >> unsicher? > > Hallo Nano, > Suchst du eigentlich für dein eigenes Garagentor eine sichere Lösung, > oder interessiert dich das im Allgemeinen? Ersteres.
Harald schrieb: > mh schrieb: >> Du fährst weg, drückst auf die Fernbedienung und das Tor >> schließt sich nicht. > > Wenn man darauf nicht achtet halte ich einen „Einbruch“ für reiflich > verdient. Nennt die Versicherung auch grobe Fahrlässigkeit. Klar kann man dann Probleme mit der Versicherung bekommen. Darum geht es aber nicht. Ich bin mir ziemlich sicher, dass die Mehrheit der Besitzer eines Garangentors mit Fernbedienung zumindest hin und wieder nicht darauf achtet, ob das Tor wirklich schließt. > mh schrieb: >> Wer sagt, dass man die Verschlüsselung mit einem Brute-force Angriff >> knacken muss? Wenn das so wäre, wäre es sehr einfach so ein Schloss zu >> bauen. Es gibt noch andere Angriffe gegen die man sich schützen muss, >> z.B. ein Replay-Angriff oder ein anderer aus der Man-in-the "Gruppe". > > Gibt es da irgendwelche Berichte, dass das schon mal so gemacht wurde? > Ich habe davon noch nichts gehört. Die ganzen Boulevard-Magazine würden > darüber doch wie bekloppt berichten. Vielleicht ist es mir auch > entgangen. Guck dir mal an wie das bei Autos gemacht wird. Da solltest du haufenweise Beispiele und Anleitungen finden können. Bei Garagen ist vermutlich die Verbreitung noch zu gering und das Kosten-Nutzen-Verhältnis nicht gut genug.
Ben Gunn schrieb: > Nano schrieb: >> Ben Gunn schrieb: >>> Sicheres Garagentor: >>> >>> RPi mit WLAN und Relais in die Garage. >> >> Ich habe mir jetzt das noch einmal genauer angesehen. > ... >> Der einzige Haken ist der lange Verbindungsaufbau und die begrenzte >> Reichweite von WLAN. Das gilt insbesondere dann, wenn der AP z.b. in der >> Garage steht und das Signal dann dadurch gedämpft wird. > > Ich würde es als Feature erachten, wenn das WLAN nur sichtbar ist, wenn > man nach davor steht. Das Spektrum ist eh schon zugemüllt. Nunja, das ist dann halt unpraktisch, weil du warten musst, bis sich das Handy endlich ins WLAN eingeloggt hat. Da steht man dann 5 s vor dem Tor und kann nicht reinfahren. > Ich verstehe dich da evtl miss. Aber mMn wäre es so wie du schreibst > Mist. Du willst ja nicht sicherstellen, dass du dich beim richtigen > RPi/Webserver anmeldest, sondern dich gegenüber dem RPi > authentifizieren. Im eigenen LAN gibt's nur einen Webserver. Wenn der RP den AP stellt, dann leitet er jede Anfrage auf sich um. Da landet man dann immer richtig. Für WLAN gibt's die MAC und SSID. > Wenn schon TLS, dann bräuchtest du hier ein > (self-signed) Client Zertifikat. Ja, kann man einrichten. Ist jetzt nicht so schwer. Die Sicherheit ist in dem Fall aber ohnehin der WLAN Schlüssel. Es schadet allerdings nicht auch für die intranet Weblösung noch https zu verwenden. > Ehrlich gesagt, finde ich SSH hier viel einfacher. Einen Toröffner-User > anlegen, Toröffner-Skript als login-shell setzen. authorized_keys. > Analog zum schließen. Fertig (sofern dir niemand die SD Karte aus der > Garage klaut). Und als Sendegerät brauchst du eines, das ssh versteht. Das ist der Nachteil. Heute haben schon Autos einen integrierten Browser, aber in den seltensten Fällen haben die auch einen ssh Clienten. Außerdem ist so ein shell Zugriff immer problematisch, sollte nämlich jemand dein Handy finden, kann er weitaus mehr machen als nur das Tor öffnen. Er könnte dann auch den Raspi umprogrammieren. Der Sprung von einfachen Rechten zu root Rechten ist schließlich nicht mehr all so weit, wenn man erstmal Zugriff auf die Maschine hat. Sobald du also das Hand verlierst und sei es nur für ein paar Stunden und der andere bringt es dir zurück, musst du deinen Raspi als kompromittiert betrachten und alles neu aufsetzen.
Harald schrieb: > Nano schrieb: >> das sind organisierte Banden >> die mit dem Auto und ihrem eingeschalteten Hackinggerät auf gut Glück >> die Straßen abfahren und dann einfach darauf achten, ob irgendwo ein >> Garagentor aufgeht. > > Ich persönlich glaube da nicht dran. Es mag noch ältere Tore aus den > 70/80er geben, die durch einfachste Funksignale zu öffnen sind. Aber bei > einem modernen Tor mit AES o.ä.? Die haben es natürlich auf die alten Garagentore > 15 Jahre ohne AES abgesehen. Bestandsbauten gibt es genug und offenbar hält es kein Hersteller für nötig, seine Altkunden über die Unsicherheit seiner alten Geräte zu informieren.
Harald schrieb: > Wenn Du sichergehen willst bau Dir was Eigenes auf. Nichts ist so > hackingsicher sicher wie eine individuelle Anlage, denn die Angriffe > richten sich IMMER gegen kommerzielle Lösungen, die in Massen > hergestellt werden. Jaja, Ich weiß, kann trotzdem alles sein wenn x und > y zusammenkommen, aber irgendwo muss man ja auch mal eine Grenze ziehen. Ja, das wäre wohl das sicherste. Ich bin mir halt nur nicht so sicher, ob das mit dem Handy besonders praktisch ist. Mein Auto ist noch nicht smart, hat also weder Apps noch nen Browser. Und eigentlich soll sich mein Handy mit meinem normalen internetfähigen LAN verbinden, nicht mit dem AP der Garage. Und den AP der Garage ins internetfähige LAN hängen will ich auch nicht. Aus Gründen der Haptik möchte ich eigentlich ein Bedienelement mit Knopf dran. Das soll sich selbstständig mit dem WLAN AP verbinden und wenn ich den Knopf drücke, soll es das Signal senden. Und das ganze Batteriebetrieben ohne großen Stromverbrauch oder gar Bootzeit. Ein Raspi im Auto ist jedenfalls nicht das was ich will. Im Prinzip hapert es hier also Clientseitig, wenn man kein Handy oder Smartauto nutzen möchte. Mit dem Raspi an der Garagentorsteuerung könnte ich leben. wobei der Stromverbrauch da auch höher sein dürfte, als so ne normale Herstellerlösung.
mh schrieb: > Guck dir mal an wie das bei Autos gemacht wird. Da solltest du > haufenweise Beispiele und Anleitungen finden können Autos ist klar, danach muss man nicht einmal suchen. Das bekommt man 2x täglich um die Ohren gehauen (OT: habe trotzdem Keyless Go und lasse es mir nicht verleiden) Konkret geht es ja um Garagentore. Also gibt es da nichts. Das da vielleicht theoretisch was geht ist mir klar. Am Ende des Tages muss man die Kirche auch mal im Dorf lassen, es geht um eine Garage. Laut Versicherungsrecht gilt z.B. auch in der Garage eine Verschlusspflicht für das Auto (wenn man Versicherungsleistung in Anspruch nehmen möchte). Falls ein Zugang zum Haus besteht muss man diese Tür sichern wie eine Außentür. Siehe Versicherungsrecht. Natürlich kann man jetzt bis zum jüngsten Tag Fälle zusammenspannen, da geht immer was.
Matthias L. schrieb: > Nano schrieb: >> Die Motorsteuerung des Tores verfügt über zwei Pins über die auch >> Universalempfänger angeschlossen werden können. > > Das ist zwar richtig, dass an die beiden Pins ein beliebig sicherer > Fernsteuer-Mechanismus angeschlossen werden kann - aber wenn der > Torantrieb ab Werk einen unsicheren Funkempfänger eingebaut haben > sollte, dann bleibt der unsicher, auch wenn du selbst ihn gar nicht > nutzt - die postulierten Panzerknacker-Banden könnten ihn dann trotzdem > anfunken. Das ist mor schon klar. Den müsste ich dann ausbauen. Funktionieren tut das allerdings nur, wenn er auf einer eigenen Platine ist.
mh schrieb: > Bei Garagen ist > vermutlich die Verbreitung noch zu gering und das > Kosten-Nutzen-Verhältnis nicht gut genug. Bei Doppelgaragen machen die Sinn. Denn die großen Tore sind recht schwer. Und je älter die Leute sind, desto sinnvoller wird es.
Nano schrieb: > Das ist mor schon klar. Den müsste ich dann ausbauen. > Funktionieren tut das allerdings nur, wenn er auf einer eigenen Platine > ist. Da es ja um ein konkret vorhandenes Modell geht, würde ich an deiner Stelle dies als erstes überprüfen... Plan B könnte evtl. noch sein, die vorhandene Antenne so zu verstümmeln, dass der Empfänger auf die Funksignale der Original-FB fast gar nicht mehr reagiert.
Zigbee mit Tradfri funktioniert vom Verbindungsaufbau viel schneller. Mit Node-Red ein Home-Automations System erstellen und schon läuft die Sache....
Nano schrieb: > Aus Gründen der Haptik möchte ich eigentlich ein Bedienelement mit Knopf > dran. Das soll sich selbstständig mit dem WLAN AP verbinden und wenn ich > den Knopf drücke, soll es das Signal senden. ESP8266. Benötigt eine einstellige Zahl von Sekunden, um sich in WLAN einzuloggen. Der Taster der FB kann einfach den Strom einschalten. Wenn man ihn loslässt, wird der ESP wieder von der Batterie getrennt. > Mit dem Raspi an der Garagentorsteuerung könnte ich leben. wobei der > Stromverbrauch da auch höher sein dürfte, als so ne normale > Herstellerlösung. Auch hier könnte man einen ESP8266 als AP nehmen.
Nano schrieb: > D.h. im Klartext, das Verfahren ist unsicher, denn gute > Kryptografieverfahren basieren darauf, dass man das > Verschlüsselungsverfahren veröffentlichen kann, ohne dass es dadurch > unsicher wird. > Also der typische Fehler von Security by Obscurity. Nein. nur wieder die gleiche leier das du gerne alles auf dem Opensource Tablett serviert bekommen möchtest um es ganz selbstverständlich kostenfrei zu nutzen... War bei der leidigen knx diskussion ja nix anderes...
ichoderso schrieb: > Nano schrieb: >> D.h. im Klartext, das Verfahren ist unsicher, denn gute >> Kryptografieverfahren basieren darauf, dass man das >> Verschlüsselungsverfahren veröffentlichen kann, ohne dass es dadurch >> unsicher wird. >> Also der typische Fehler von Security by Obscurity. > > Nein. nur wieder die gleiche leier das du gerne alles auf dem Opensource > Tablett serviert bekommen möchtest um es ganz selbstverständlich > kostenfrei zu nutzen... > > War bei der leidigen knx diskussion ja nix anderes... https://de.wikipedia.org/wiki/Security_through_obscurity
Frank M. schrieb: > Nano schrieb: >> Aus Gründen der Haptik möchte ich eigentlich ein Bedienelement mit Knopf >> dran. Das soll sich selbstständig mit dem WLAN AP verbinden und wenn ich >> den Knopf drücke, soll es das Signal senden. > > ESP8266. Benötigt eine einstellige Zahl von Sekunden, um sich in WLAN > einzuloggen. Der Taster der FB kann einfach den Strom einschalten. Wenn > man ihn loslässt, wird der ESP wieder von der Batterie getrennt. > >> Mit dem Raspi an der Garagentorsteuerung könnte ich leben. wobei der >> Stromverbrauch da auch höher sein dürfte, als so ne normale >> Herstellerlösung. > > Auch hier könnte man einen ESP8266 als AP nehmen. Wichtig ist mMn aber zu erwähnen, dass man wissen muss, welchen Komponenten man vertrauen muss. Nutzt man SSH oder TLS/HTTPS mit Server und Client Zertifikaten, ist die WLAN-/Zigbee-/Bluetooth-/Infrarot-/...Sicherheit irrelevant. Es ist einfach nur ein Protokoll um Daten drahtlos auszutauschen. Vertraut man der Sicherheit der Wirelessprotokolle, gibt es auf einen Schlag einen Strauß an Fallstricken (WLAN AP Zertifikate, Radius, Client Zertifikate, ...). Wenn der Stromverbrauch ein Problem darstellt, kann man sich auch überlegen den Rechner ("RPi" synonym verwendet für "Linux-Kleinstrechner") nur bei Bedarf einuschalten. Wenn man den z.B. in die initrd booten lässt geht das auch in << 5s.
Wenn es nur ein Knopf sein soll, dann würde ich über RFID-Lösungen nachdenken und ein UND-Glied einbauen. Also z.B. RFID und MAC des Handys abfragen. Ein Einbrecher, der BEIDES hat, wird selten sein. Frage ist eher, ob es 100 Jahre zuverlässig funktioniert.
Harald schrieb: > Gibt es da irgendwelche Berichte, dass das schon mal so gemacht wurde? > Ich habe davon noch nichts gehört. Die ganzen Boulevard-Magazine würden > darüber doch wie bekloppt berichten. Vielleicht ist es mir auch > entgangen. Nein, warum auch. Der normale Einbrecher nimmt sein Brecheisen, und biegt das 2mm Blech des Tors in Sekundenschnelle mal eben geräuschlos zur Seite. Mechanisch ist so ein Garagentor doch eher ein Sichtschutz, und kein Tor. Oliver
Ben Gunn schrieb: > Wichtig ist mMn aber zu erwähnen, dass man wissen muss, welchen > Komponenten man vertrauen muss. Nutzt man SSH oder TLS/HTTPS mit Server > und Client Zertifikaten, ist die > WLAN-/Zigbee-/Bluetooth-/Infrarot-/...Sicherheit irrelevant. Nein! WLAN/Zigbee/Bluetooth/Infrarot/... bleiben immer noch eine Angriffsfläche.
Bei mir wäre irgendeine WLAN/RasPi/etc.-Lösung raus. Mögliche Schwachstellen/Angriffsszenarien multiplizieren sich einfach zu schnell. Ich bin da für ein System µC zu µC mit eigenem Funkkanal, komplett nach außen hin gekaspelt (in Bezug auf andere Schnittstellen). Da hier vermutlich einige dabei sind, die bzgl. Funkmodul und Reichweite mehr Erfahrung haben, eine Zwischenfrage: welches Modul auf 433 oder 800MHz passt zusammen mit einem µC in einen kleinen Handsender? Hier haben ich und andere übrigens schon etwas länger über eine saubere Authentifizierungsmethode diskutiert mit mMn brauchbaren Ergebnissen: Beitrag "AES Verschlüsselung, frage so Vorhersehbarkeit" Insbesondere die letzte Lösung mit einem simplen Zähler gefällt mir, da dabei nur unidirektionale Kommunikation notwendig ist. Das Garagentor sendet also niemals, was die Sicherheit nochmal erhöht.
:
Bearbeitet durch Moderator
Chris D. schrieb: > Hier haben ich und andere übrigens schon etwas länger über eine saubere > Authentifizierungsmethode diskutiert mit mMn brauchbaren Ergebnissen: > > Beitrag "AES Verschlüsselung, frage so Vorhersehbarkeit" > > Insbesondere die letzte Lösung mit einem simplen Zähler gefällt mir, da > dabei nur unidirektionale Kommunikation notwendig ist. Das Garagentor > sendet also niemals, was die Sicherheit nochmal erhöht. Und da wurde auch darauf hingewiesen, dass das anfällig gegenüber einfachen Replay-Angriffen ist.
Beitrag #6456461 wurde vom Autor gelöscht.
Stimmt, hast Recht. Also muss man doch mit Challenge/Response arbeiten.
Chris D. schrieb: > Insbesondere die letzte Lösung mit einem simplen Zähler gefällt mir, Noch einfacherer Vorschlag ohne Verschlüsselung. - Auf beiden Seiten ein serielles EEPROM (z.b. 128Kx8) - Beide EEPROMs werden identisch beschrieben mit denselben Zufallszahlen - Sender sendet Zähler Z + Zufallszahl in Slot Z aus dem EEPROM - Empfänger liest in Slot Z die Zufallszahl und vergleicht sie Nehmen wir an, jeder Slot wäre 4 Bytes (32 Bits) lang. Dann hätte man auf einem 128Kx8 EEPROM 32768 Slots. Man könnte das Garagentor also 32768 mal mit komplett verschiedenen 32-Bit-Codes öffnen. Danach (also nach vielen Jahren) muss man die EEPROMs neu "auftanken". Wenn man es sicherer haben möchte, nimmt man als Slotlänge 8 Bytes (64 Bits). Dann sind immehin noch 16384 Öffnungen möglich. Würde das so funktionieren? Wo sind Angriffspunkte? Wie sicher ist das gegen Brute-Force?
:
Bearbeitet durch Moderator
Frank M. schrieb: > Würde das so funktionieren? Wo sind Angriffspunkte? Wie sicher ist das > gegen Brute-Force? Replay-Angriff
mh schrieb: > Frank M. schrieb: > Würde das so funktionieren? Wo sind Angriffspunkte? Wie sicher ist das > gegen Brute-Force? > > Replay-Angriff Nö, der Zähler wird ja hochgezählt und damit ein alter Slot unbenutzbar.
mh schrieb: > Frank M. schrieb: >> Würde das so funktionieren? Wo sind Angriffspunkte? Wie sicher ist das >> gegen Brute-Force? > > Replay-Angriff Jepp. Man kann leider nicht garantieren, dass der Empfänger in der Garage jedes gesendete Paket auch erhält. Unidirektional ginge nur, wenn auf beiden Seiten eine sehr genau abgeglichene Uhr (welcher Form auch immer) liefe - mit entsprechenden Problemen. Also bleibt nur, dass der Sender etwas wie "Ich bin da" schickt, das Garagentor mit der Aufgabe antwortet, und der Sender dann die gelöste Aufgabe zurückschickt. Das wäre dann sicher, erfordert aber leider auf beiden Seiten Sender und Empfänger.
Frank M. schrieb: > mh schrieb: >> Frank M. schrieb: >> Würde das so funktionieren? Wo sind Angriffspunkte? Wie sicher ist das >> gegen Brute-Force? >> >> Replay-Angriff > > Nö, der Zähler wird ja hochgezählt und damit ein alter Slot unbenutzbar. Szenario: - "Guter Sender" sendet - Empfänger sieht das Paket aber gar nicht, dafür der Empänger des "bösen Senders" - "Böser Sender" sendet selbst das Paket und diesmal sieht der Empfänger das Paket
:
Bearbeitet durch Moderator
Chris D. schrieb: > Jepp. Man kann leider nicht garantieren, dass der Empfänger in der > Garage jedes gesendete Paket auch erhält. Du hattest doch selbst in dem von Dir zitierten Thread ein "Window" vorgeschlagen, also einen Bereich, in dem der nächste gesandte Zähler liegen muss - z.B. einen erlaubten Offset von +1 bis + 128. So kann die Person außerhalb des Empfangsbereichs 128 mal den Taster benutzen, bevor der Sender unbrauchbar wird. Erlaubt sind natürlich nur Slot-Nummern, die größer als die letzte empfangene Slot-Nummer sind - aber maximal +128 Slots.
:
Bearbeitet durch Moderator
Frank M. schrieb: > Chris D. schrieb: >> Jepp. Man kann leider nicht garantieren, dass der Empfänger in der >> Garage jedes gesendete Paket auch erhält. > > Du hattest doch selbst in dem von Dir zitierten Thread ein "Window" > vorgeschlagen, also einen Bereich, in dem der nächste gesandte Zähler > liegen muss - z.B. einen erlaubten Offset von +1 bis + 128. > > So kann die Person außerhalb des Empfangsbereichs 128 mal den Taster > benutzen, bevor der Sender unbrauchbar wird. Ist richtig, ändert aber nichts am Szenario "Es wird zwar gesendet, aber der Empfänger registriert das erstmal nicht". Es gibt unidirektional für den Empfänger keine Möglichkeit, zu entscheiden, ob das Paket wirklich von meinem Sender oder einem anderen kommt,der das vorher abgefangen hat. Das Problem ist eben, dass man nicht garantieren kann, dass das Garagentor jedes Paket empfängt. Und ein nichtempfangenes Paket kann ein mithörender Angreifer dann verwenden.
:
Bearbeitet durch Moderator
Chris D. schrieb: > Es gibt unidirektional für den Empfänger keine Möglichkeit, zu > entscheiden, ob das Paket wirklich von meinem Sender oder einem anderen > kommt, Achso, Du meinst folgendes Szenario? - Original-Sender sendet Zufallszahl Z aus Slot N - Garagentor-Empfänger empfängt diesen nicht - aus welchen Gründen auch immer - und kann daher den Zähler nicht hochzählen. - Ein "Lauscher" empfängt genau diesen Code - Der Lauscher probiert es mit dieser empfangenen Kombination aus N + Z Hm, da muss ich mal drüber nachdenken. EDIT: Habe jetzt gesehen, dass Du Deinen Beitrag nochmal editiert hast. Ja, Du meinst dasselbe. Und Du hast natürlich Recht :-)
:
Bearbeitet durch Moderator
Frank M. schrieb: > - Der Lauscher probiert es mit dieser empfangenen Kombination aus N + Z Er benötigt nicht mal +Z - er nimmt einfach direkt dieses Paket und sendet es einfach nochmal. :-/ > Hm, da muss ich mal drüber nachdenken. Wenn Du eine unidirektionale Lösung ohne größeren Aufwand (exakt synchronisierte Uhren etc.) findest - ich wäre sehr interessiert :-)
Chris D. schrieb: > Wenn Du eine unidirektionale Lösung ohne größeren Aufwand (exakt > synchronisierte Uhren etc.) findest - ich wäre sehr interessiert :-) Müssen die Uhren exakt synchronisiert sein? Ich kenne zum Beispiel Anwendungen, die mit dem Google Authenticator arbeiten. Hier wird jede Minute eine neue Zufallszahl generiert. Außerdem akzeptiert der Empfänger auch noch die Zufallszahl aus der letzten Minute. Damit können die Uhren bis zu 2 Minuten auseinanderlaufen.
Dieter schrieb: > Der Theoretiker braucht es natürlich nur für seine eigene Garage > umzusetzen. Alle anderen Fallvarianten können ihm da egal sein. > Wenn dieser seine benötigten Mannstunden ansetzt und sich ansieht > wieviel Mehrfaches an Mannstunden die Hersteller könnten, würde das > reichen für die Erweiterung auf viele andere Fallvarianten. Billige Ausrede, um ungeeigneten Müll als sicher zu verkaufen. Frank M. schrieb: > - Auf beiden Seiten ein serielles EEPROM (z.b. 128Kx8) > - Beide EEPROMs werden identisch beschrieben mit denselben Zufallszahlen > - Sender sendet Zähler Z + Zufallszahl in Slot Z aus dem EEPROM > - Empfänger liest in Slot Z die Zufallszahl und vergleicht sie > > Nehmen wir an, jeder Slot wäre 4 Bytes (32 Bits) lang. Dann hätte man > auf einem 128Kx8 EEPROM 32768 Slots. Man könnte das Garagentor also > 32768 mal mit komplett verschiedenen 32-Bit-Codes öffnen. Danach (also > nach vielen Jahren) muss man die EEPROMs neu "auftanken". > > Wenn man es sicherer haben möchte, nimmt man als Slotlänge 8 Bytes (64 > Bits). Dann sind immehin noch 16384 Öffnungen möglich. Dann hast du aber das Problem, dass jede Fernbedienung ein EEPROM benötigt, das zum Tor passt. Praktisch setzt man also einen Algorithmus (indizierter Pseudozufallsgenerator oder ein beliebiges, starkes Verschlüsselungsverfahren) ein, womit ganz ohne EEPROM der Code aus dem Index generiert werden kann. Um die Tore zu individualisieren, wird von außen ein "Offset" konfiguriert. Praktisch wurde (wird?) sowas umgesetzt indem man der Fernbedienung und dem Torantrieb einen Haufen DIP-Switches verpasst. Nachdem aber DIP-Switches die Fernbedienung groß machen, die Einstellerei unsexy ist und vom Kunden die Switches einfach am Werkszustand belassen werden, womit die Sicherheit dahin ist. Praktisch wird heute also z.B. das mittlerweile KeeLoq verwendet: http://ww1.microchip.com/downloads/en/AppNotes/00001683A.pdf
100Ω W. schrieb: > Nano schrieb: >> Für WLAN gibt's die MAC und SSID. > > Das Fälschen davon ist keine Kunst. Ja, habe ich auch nicht behauptet. Wenn das aber jemand macht, gibt's ohnehin nen Konflikt, wenn da plötzlich zwei identische APs stehen
Frank M. schrieb: > Noch einfacherer Vorschlag ohne Verschlüsselung. > > - Auf beiden Seiten ein serielles EEPROM (z.b. 128Kx8) > - Beide EEPROMs werden identisch beschrieben mit denselben Zufallszahlen > - Sender sendet Zähler Z + Zufallszahl in Slot Z aus dem EEPROM > - Empfänger liest in Slot Z die Zufallszahl und vergleicht sie > > .... > > Würde das so funktionieren? Wo sind Angriffspunkte? Wie sicher ist das > gegen Brute-Force? Warum nicht einfach ein RSA-Algorithmus mit öffentlichem und geheimen Schlüssel wie man es auch von PGP her kennt?
Nano schrieb: > Warum nicht einfach ein RSA-Algorithmus mit öffentlichem und geheimen > Schlüssel wie man es auch von PGP her kennt? Replay? Ich glaube man kommt nicht um einen bidirektionalen Kommunikationskanal herum. Alternative wären synchronisierte Uhren, was auch einen - wie immer gearteten - Empfänger im Sender erforderlich macht.
mh schrieb: > Ben Gunn schrieb: >> Wichtig ist mMn aber zu erwähnen, dass man wissen muss, welchen >> Komponenten man vertrauen muss. Nutzt man SSH oder TLS/HTTPS mit Server >> und Client Zertifikaten, ist die >> WLAN-/Zigbee-/Bluetooth-/Infrarot-/...Sicherheit irrelevant. > > Nein! WLAN/Zigbee/Bluetooth/Infrarot/... bleiben immer noch eine > Angriffsfläche. Wieso sollten sie, wenn ich ihnen nicht vertrauen muss? Man könnte den Toröffner-Rechner auch per SMS, Kabel, oder Morsetaste anschließen. SSH ist das egal.
Frank M. schrieb: > Müssen die Uhren exakt synchronisiert sein? Ich kenne zum Beispiel > Anwendungen, die mit dem Google Authenticator arbeiten. Hier wird jede > Minute eine neue Zufallszahl generiert. Außerdem akzeptiert der > Empfänger auch noch die Zufallszahl aus der letzten Minute. Damit können > die Uhren bis zu 2 Minuten auseinanderlaufen. Diese 2-Faktor-Authentifizierung mit TOTP wurde genau deshalb erfunden, weil das vorher verwendete HOTP (das ist das mit dem hochzählenden Zähler in Sender und Empfänger) nicht wirklich praktikabel ist. Das Verfahren ist das gleiche, nur wird an Stelle des Zählers die Uhrzeit benutzt, in 30-Sekunden-Schritten (nicht pro Minute). Und mit ziemlicher Sicherheit wird es da ein paar Sekunden Toleranz geben. Und selbst, wenn nicht, muß man halt zur Not zweimal auf den Knopf drücken. Oliver
:
Bearbeitet durch User
Nano schrieb: > Seine neuste Technologie ist ein 128 Bit Verschlüsselungsverfahren wie > beim Online Banking und zusätzlich ein Rolling Code Verfahren und er > wirbt damit, dass nur den hausinternen Ingenieuren mitgeteilt wird, wie > das Verfahren genau funktioniert. > > D.h. im Klartext, das Verfahren ist unsicher, Nein, das bedeutet es nicht zwingend. > denn gute > Kryptografieverfahren basieren darauf, dass man das > Verschlüsselungsverfahren veröffentlichen kann, ohne dass es dadurch > unsicher wird. Nein, darauf basieren tun sie gewiss nicht. Diese Eigenschaft ist allerdings ein Qualitätsmerkmal. > Also der typische Fehler von Security by Obscurity. Das muss keineswegs sein. Es gibt verschiedene offengelegte Verschlüsselungsmethoden, die als einigermaßen sicher gelten. Wenn der Hersteller eines davon aussucht, ohne öffentlich zu machen, welches, wird das gewählte Verfahren dadurch nicht unsicher. Aber der überängstliche Kunde freut sich über einen vermeintlichen Sicherheitsgewinn. Das mag unberechtigt sein; weniger sicher wird das Verfahren dadurch jedoch nicht.
Frank M. schrieb: > Nano schrieb: >> Warum nicht einfach ein RSA-Algorithmus mit öffentlichem und geheimen >> Schlüssel wie man es auch von PGP her kennt? > > Replay? Das kann man ja recht einfach verhindern in dem man eine Zufallszahl einbaut. Handgerät verschlüsselt mit Pulic Key von Garage die Nachricht, bitte sende mir nen Zufallscode. Garage generiert einen Zufallscode und verschlüsselt ihn mit dem Public Key vom Handgerät. Das Handgerät verrechnet nun den Zufallscode mit einer anderen geheimen Zahl, auf die man sich vorher geeinigt hat, oder man macht es noch komplizierter und das Handgerät sendet auch einen Zufallscode. Das Ergebnis wird dann mit dem Public Key der Garage verschlüsselt und an diese gesendet. Die Garage vergleicht das Ergebnis mit der eigenen Rechnung und macht dann das Tor auf oder verweigert dies. Da sich die Zufallszahl immer ändert, und ein Angreifer weder die Zufallszahl noch den privaten Key kennt, hat er keine Chance. Sicherlich gibt's dafür auch schon bekannte bewährte Verfahren, die man verwenden kann, so dass man das nicht von neuem erfinden muss. Ich habe das Beispiel nur mal erwähnt, wie man das grob lösen könnte. > Ich glaube man kommt nicht um einen bidirektionalen Kommunikationskanal > herum. Ja, so sehe ich das auch.
Percy N. schrieb: > Aber der > überängstliche Kunde freut sich über einen vermeintlichen > Sicherheitsgewinn. Das mag unberechtigt sein; weniger sicher wird das > Verfahren dadurch jedoch nicht. Mir fehlt da einfach die Transparenz. Ein Hersteller, der sein verwendetes Verfahren geheim halten muss, erweckt bei mir kein Sicherheitsgefühl oder Vertrauen in dessen Sicherheit.
Percy N. schrieb: > Nano schrieb: >> Seine neuste Technologie ist ein 128 Bit Verschlüsselungsverfahren wie >> beim Online Banking und zusätzlich ein Rolling Code Verfahren und er >> wirbt damit, dass nur den hausinternen Ingenieuren mitgeteilt wird, wie >> das Verfahren genau funktioniert. >> D.h. im Klartext, das Verfahren ist unsicher, > Nein, das bedeutet es nicht zwingend. Ergänzung: Da hast Du nicht sorgfältig genug gelesen, und ich Depp habe mich auf Deine vertrottelten Angaben verlassen. Eine Nachschau im verlinkten Text ergibt, dass "die Funktechnik" lediglich den hauseigenen Ingenieuren bekannt sei (was vermutlich Blödsinn sein dürfte, jedoch nicht das geringste mit der Schlüsseltechnik zu tun haben dürfte): "Die Funktechnik ist ausschließlich unseren Ingenieuren bekannt, zudem produzieren wir alle unsere bi·linked Funkprodukte in unseren eigenen Werken."
Nano schrieb: > Ersteres Dann schau dir das mal an: Meross Smart WLAN Garagentoröffner Hab das mehrfach im Einsatz, bin sehr zufrieden. https://www.amazon.de/dp/B08HV41Q5W/ref=cm_sw_r_oth_api_i_tZfMFbVQFV0RT
:
Bearbeitet durch User
Percy N. schrieb: > Percy N. schrieb: >> Nano schrieb: >>> Seine neuste Technologie ist ein 128 Bit Verschlüsselungsverfahren wie >>> beim Online Banking und zusätzlich ein Rolling Code Verfahren und er >>> wirbt damit, dass nur den hausinternen Ingenieuren mitgeteilt wird, wie >>> das Verfahren genau funktioniert. >>> D.h. im Klartext, das Verfahren ist unsicher, >> Nein, das bedeutet es nicht zwingend. > > Ergänzung: Da hast Du nicht sorgfältig genug gelesen, und ich Depp habe > mich auf Deine vertrottelten Angaben verlassen. Eine Nachschau im > verlinkten Text ergibt, dass "die Funktechnik" lediglich den hauseigenen > Ingenieuren bekannt sei (was vermutlich Blödsinn sein dürfte, jedoch > nicht das geringste mit der Schlüsseltechnik zu tun haben dürfte): > > "Die Funktechnik ist ausschließlich unseren Ingenieuren bekannt, zudem > produzieren wir alle unsere bi·linked Funkprodukte in unseren eigenen > Werken." Vom Kontext her kannst du davon ausgehen, dass die damit alles meinen, also nicht nur das Funkprotokoll, sondern eben auch den Sicherheitsanteil davon. Der Text richtet sich schließlich an Laien, die erwähnen ja nicht einmal, dass sie AES verwenden, sondern umschreiben es blumig mit "wie beim Online Banking". AES wird, sofern richtig implementiert, sicher sein, aber dieser Rolling Code klingt nach was selbstgestricktem. Letzten Endes gibt es eben keine Transparenz, wie es genau gemacht wird, kein Dritter weiß, ob die verwendeten Zufallszahlen was taugen oder nur so eine Pseudozufallszahlengeschichte mit beschränktem Zahlenraum sind, also gilt Security through Obscruity und deswegen ist vom Worst Case Fall auszugehen, was wiederum bedeutet, dass es eben unsicher ist. Sicherheit gibt's eben nur durch nen öffentlichen Audit und das kann oder will dieser Hersteller nicht liefern.
Thomas K. schrieb: > Nano schrieb: >> Ersteres > > Dann schau dir das mal an: > > Meross Smart WLAN Garagentoröffner > > > Hab das mehrfach im Einsatz, bin sehr zufrieden. > > https://www.amazon.de/dp/B08HV41Q5W/ref=cm_sw_r_oth_api_i_tZfMFbVQFV0RT Danke für den Link, ich werde es mir mal anschauen. Allerdings habe ich kein iPhone und eigentlich will ich auch keine vom Smartphone abhängige Lösung. Denn beim Smartphone geht mir der Akku zu schnell leer. Ich bevorzuge ein Lösung mit Handgerät, bei dem die Batterie oder der Akku ein paar Monate hält.
Nano schrieb: > Vom Kontext her kannst du davon ausgehen, dass die damit alles meinen, > also nicht nur das Funkprotokoll, sondern eben auch den > Sicherheitsanteil davon. Gerade nicht. > Der Text richtet sich schließlich an Laien, die erwähnen ja nicht > einmal, dass sie AES verwenden, sondern umschreiben es blumig mit "wie > beim Online Banking". > Eben. Und eben diese Laien kann man wundervoll mit Heimlichtuerei einwickeln und mit Offenlegung verschrecken. Und wenn man dann anerkannte Standards verwendet, die offengelegt wurden, lässt sich der erwünschte Eindruck der Heimlichkeit ohne allzu heftige Wettbewerbsverstöße allenfalls noch hinsichtlich der Funktechnik einigermaßen schwammig behaupten. > AES wird, sofern richtig implementiert, sicher sein, aber dieser Rolling > Code klingt nach was selbstgestricktem. Ja, und? Wird die Sicherheit von AES dadurch beeinträchtigt? > Letzten Endes gibt es eben keine Transparenz, wie es genau gemacht wird, > kein Dritter weiß, ob die verwendeten Zufallszahlen was taugen oder nur > so eine Pseudozufallszahlengeschichte mit beschränktem Zahlenraum sind, Sofern AES lege artis implementiert wurde, kommt es darauf nicht an. > also gilt Security through Obscruity und deswegen ist vom Worst Case > Fall auszugehen, was wiederum bedeutet, dass es eben unsicher ist. > Das ist hier nicht richtig. > Sicherheit gibt's eben nur durch nen öffentlichen Audit und das kann > oder will dieser Hersteller nicht liefern. Das können wir überhaupt nicht wissen, da er insoweit keinerlei Angaben gemacht hat.
:
Bearbeitet durch User
Nano schrieb: > Frank M. schrieb: >> Nano schrieb: >>> Warum nicht einfach ein RSA-Algorithmus mit öffentlichem und geheimen >>> Schlüssel wie man es auch von PGP her kennt? >> >> Replay? > > Das kann man ja recht einfach verhindern in dem man eine Zufallszahl > einbaut. > > [...] > > Da sich die Zufallszahl immer ändert, und ein Angreifer weder die > Zufallszahl noch den privaten Key kennt, hat er keine Chance. Jetzt sind wir so langsam bei einem Verfahren angekommen, das sicher sein kann. Du musst nur noch eine Möglichkeit finden, mit der du die Public Keys austauschst und das ganze ohne Fehler implementieren. Der Denial-of-Service Angriff beim Schießen des Tores funktioniert allerdings immer noch. Ben Gunn schrieb: > mh schrieb: >> Ben Gunn schrieb: >>> Wichtig ist mMn aber zu erwähnen, dass man wissen muss, welchen >>> Komponenten man vertrauen muss. Nutzt man SSH oder TLS/HTTPS mit Server >>> und Client Zertifikaten, ist die >>> WLAN-/Zigbee-/Bluetooth-/Infrarot-/...Sicherheit irrelevant. >> >> Nein! WLAN/Zigbee/Bluetooth/Infrarot/... bleiben immer noch eine >> Angriffsfläche. > > Wieso sollten sie, wenn ich ihnen nicht vertrauen muss? Man könnte den > Toröffner-Rechner auch per SMS, Kabel, oder Morsetaste anschließen. SSH > ist das egal. Weil das immer noch Einfallstore in das System sind. Der Denial-of-Service Angriff beim Schießen des Tores funktioniert auch, wenn du das WLAN/Zigbee/Bluetooth/Infrarot/... lahm legst.
https://www.saltosystems.com/de-de/produktportfolio/product/543/danalock-universalmodul/ Aktuell öffnet noch die Fritzbox das Tor indirekt über einen RasPi Zero. Vorteil: Schon 1km vor dem heimischen Tor kann ich dem ankündigen das ich rein will. Entweder per Rufnummer (optional mit Code), oder aber per freigeschaltetem RasPi zum Öffnen/Schließen via WLAN. https://wiki.zebradem.com/wiki/?title=HowTo_mit_Handy_oder_Haustelefon_über_Fritzbox_die_Haustür/Garagentor_zu_öffnen
mh schrieb: > Jetzt sind wir so langsam bei einem Verfahren angekommen, das sicher > sein kann. Du musst nur noch eine Möglichkeit finden, mit der du die > Public Keys austauschst und das ganze ohne Fehler implementieren. Und damit sind wir wieder beim oben genannten Hörmann-Antrieb. Dessen Verschlüsselungsverfahren ans sich ist sicher, nur fehlerhaft implementiert. Wenn die das, wie im Artikel geschrieben wurde, inzwischen gefixt haben, wird da niemand das Tor durch hacken der Verschlüsselung öffnen. Auch vorher war die Gefahr gering. Dass das Verfahren prinzipiell gehackt werden kann, heißt ja nicht, dass das jeder kann. Da muß schon jemand mit entsprechenden Kenntnissen ein Gerät entwickeln, das den Vorgang automatisiert, und das über die übliche Kanäle zum Kauf anbieten. Und zur Anwendung wird man damit dann einige Öffnungsvorgänge aufzeichnen müssen, um den Key zu berechnen. Bei Autos läuft das so, aber Garagentorantriebe sind dafür einfach kein lohnendes Ziel. Da lohnt der Aufwand nicht, Brecheisen reicht. Oliver
:
Bearbeitet durch User
> Ben Gunn schrieb: >> mh schrieb: >>> Nein! WLAN/Zigbee/Bluetooth/Infrarot/... bleiben immer noch eine >>> Angriffsfläche. >> >> Wieso sollten sie, wenn ich ihnen nicht vertrauen muss? Man könnte den >> Toröffner-Rechner auch per SMS, Kabel, oder Morsetaste anschließen. SSH >> ist das egal. > > Weil das immer noch Einfallstore in das System sind. Der > Denial-of-Service Angriff beim Schießen des Tores funktioniert auch, > wenn du das WLAN/Zigbee/Bluetooth/Infrarot/... lahm legst. Halte ich für ein Scheinargument. Ich fahre doch nicht weg, solange sich das Tor noch nicht schließt bzw. es noch offen ist! Auch mit HOTP und ähnlichen oben diskutierten Verfahren hast du das gleiche Problem, weil wireless einfach anfällig gegen DoS ist. Wenn die Torsteuerung ein (authentifiziertes) ACK auf den Schließbefehl sendet, kannst du theoretisch wegfahren. Praktisch kann dann trotzdem jemand einfach etwas unter das sich schließende Tor werfen und verkeilen, sobald du hinter der nächsten Kurve oder außer Sichtweite bist. Siehe auch weiter oben Beitrag "Re: Gibts's irgendwo ne Liste mit unsicheren automatischen Garagentoren?"
mh schrieb: > Du musst nur noch eine Möglichkeit finden, mit der du die > Public Keys austauschst und das ganze ohne Fehler implementieren. Ich würde es über eine USB Schnittstelle als Programmierschnittstelle implementieren oder über eine SD Card, die die Daten enthält und man dann in das Gerät steckt. D.h. Handgerät und Garagentorgerät kriegt ne USB Schnittstelle. Da schließt man dann ein Notebook, Smartphone, Tablet usw. an und gibt ihm nen neuen private Key und verteilt gleich noch die richtigen public Keys. > Der > Denial-of-Service Angriff beim Schießen des Tores funktioniert > allerdings immer noch. Einen DoS wird man wohl nicht loswerden. Das sehe ich jetzt aber auch nicht als großes Problem an. Notfalls macht man in der Garage nen Schalter hin, der das Tor dann zumacht, wenn er gedrückt wird. Die meisten automatischen Tore haben den ohnehin. Dann muss man zwar aussteigen, aber das Tor kriegt man so auf jeden Fall zu.
mh schrieb: > Jetzt sind wir so langsam bei einem Verfahren angekommen, das sicher > sein kann. Du musst nur noch eine Möglichkeit finden, mit der du die > Public Keys austauschst und das ganze ohne Fehler implementieren. Der > Denial-of-Service Angriff beim Schießen des Tores funktioniert > allerdings immer noch. Diffie-Hellman (https://de.wikipedia.org/wiki/Diffie-Hellman-Schl%C3%BCsselaustausch)? In der Kryptographie sind das alles gelöste Probleme. Sie sind halt aufwändig zu implementieren (weil man hier nicht einfach auf e.g. OpenSSL zurückgreifen kann, sondern das in einer kleinen MCU unterbringen muss). Ausserdem ist die Schlüsselverwaltung (also die kryptographischen) dann nicht mehr trivial, man will ja ggf. mehrere Sender und die auch mal ersetzen können. Und wenn man ohnehin eine bidirektionale Kommunikation hat, kann die Garage auch zurückübermitteln, das (und was) sie empfangen hat. Dann kann man zwar immer noch DoS machen, aber der Sender kann es erkennen.
Oliver S. schrieb: > Und damit sind wir wieder beim oben genannten Hörmann-Antrieb. Hast du einen Link, in dem das genutzte Verfahren und das Problem damit beschrieben wird? Ben Gunn schrieb: > Halte ich für ein Scheinargument. > > Ich fahre doch nicht weg, solange sich das Tor noch nicht schließt bzw. > es noch offen ist! Auch mit HOTP und ähnlichen oben diskutierten > Verfahren hast du das gleiche Problem, weil wireless einfach anfällig > gegen DoS ist. Das mag auf dich zutreffen. Die meisten Leute kaufen sich diese Systeme, damit sie einfach wegfahren können. Wo ist sonst der Vorteil von dem Funksystem? Aussteigen, Tor schließen, einsteigen ist häufig schneller als warten bis der unterdimensionierte Motor das Tor schließt. Und wenn man so ein System verkaufen und als sicher bezeichnen möchte, ist das ein relevanter Faktor.
Hendrik L. schrieb: > sondern das in einer kleinen MCU > unterbringen muss). Gibt's eigentlich MCUs mit eingebautem Rauschgenerator oder gutem Zufallsgenerator? Das könnte ich mir noch als Problem vorstellen, denn woher soll er sonst die Zufallszahlen hernehmen? Viele Eingabemöglichkeiten hat so ein Handgerät mit nur einem Button ja nicht.
mh schrieb: > Die meisten Leute kaufen sich diese Systeme, > damit sie einfach wegfahren können. Wo ist sonst der Vorteil von dem > Funksystem? Oben habe ich es schon erwähnt. Doppelgaragen sind schwer, je älter man wird, desto größer wird es zu einem Problem. Da hilft dann jede Automatik. Und wenn man die Motorsteuerung schon drin hat, dann ist die Funksteuerung der nächste logische Schritt, ohne man den nicht auskommen möchte. Denn wozu sollte man schließlich wieder aus dem Auto aussteigen, nur um automatische Tor zu schließen, wenn Funk mehr als naheliegend ist? Also macht man das per Funk, weil es geht und Sinn macht.
Hendrik L. schrieb: > mh schrieb: >> [...], mit der du die Public Keys austauschst [...] > > Diffie-Hellman > (https://de.wikipedia.org/wiki/Diffie-Hellman-Schl%C3%BCsselaustausch)? > In der Kryptographie sind das alles gelöste Probleme. Sie sind halt > aufwändig zu implementieren (weil man hier nicht einfach auf e.g. > OpenSSL zurückgreifen kann, sondern das in einer kleinen MCU > unterbringen muss). Ausserdem ist die Schlüsselverwaltung (also die > kryptographischen) dann nicht mehr trivial, man will ja ggf. mehrere > Sender und die auch mal ersetzen können. > Und wenn man ohnehin eine bidirektionale Kommunikation hat, kann die > Garage auch zurückübermitteln, das (und was) sie empfangen hat. Dann > kann man zwar immer noch DoS machen, aber der Sender kann es erkennen. Diffie-Hellman löst das Problem nicht. Das ist im wesentlichen das Verfahren, das Nano beschrieben hat in dem Post auf den ich geantwortet habe. Wie bekomme ich den Public Key einer neuen Fernbedienung in das Schloss und den Public Key des Schlosses in die Fernbedienung? Wir sind jetzt bei einem System angekommen, das -genug Rechenpower hat für einen aktuellen Krypto-Algo -genug Speicher hat um mehrere Public und einen Private Key zu speichern -eine Funkschnittstelle hat die --genug Reichweite hat --in einem geschlossenen Auto funktioniert --zuverlässig "große" Datenmengen fehlerfrei überträgt -eine Schnittstelle zum Austausch der Public Keys hat -den aktuellen Zustand des Tores überwacht Möchte jemand eine Schätzung abgeben, was die zusätzlichen Kosten für den Endkunden bei einem derartiges System sind, bei einer Stückzahl von vielleicht 1000/Jahr?
mh schrieb: > Das mag auf dich zutreffen. Die meisten Leute kaufen sich diese Systeme, > damit sie einfach wegfahren können. Wo ist sonst der Vorteil von dem > Funksystem? Aussteigen, Tor schließen, einsteigen ist häufig schneller > als warten bis der unterdimensionierte Motor das Tor schließt. > > Und wenn man so ein System verkaufen und als sicher bezeichnen möchte, > ist das ein relevanter Faktor. Also ich kenne wirklich niemanden, der wegfährt, ohne zumindest das beginnende Schließen abzuwarten. Und wenn das Tor runterfährt, dann kommt jeder DoS zu spät. Da hilft es dann nur noch, den angesprochenen Knüppel dazwischenzuschmeißen - ein Szenario, das ich für deutlich wahrscheinlicher als einen DoS halte. Beginnt es nicht runterzufahren, dann macht man genau das, was Nano ansprach: aussteigen und Taster drücken (so wie auch bei leerer Senderbatterie). Auch das ist dann DoS-sicher. Wenn man aber gar nicht auf das Tor schauen möchte, dann spricht ja nichts dagegen, dass das Tor noch eine Quittung "Schließe jetzt" absendet und der Sender eine LED leuchten lässt oder vibriert :-) Aber auch dann kann mittendrin der Strom ausfallen - also braucht man eine Notstromversorgung ...
:
Bearbeitet durch Moderator
mh schrieb: > Wie bekomme ich den Public Key einer neuen Fernbedienung in das Schloss > und den Public Key des Schlosses in die Fernbedienung? > > Wir sind jetzt bei einem System angekommen, das > > -genug Rechenpower hat für einen aktuellen Krypto-Algo > -genug Speicher hat um mehrere Public und einen Private Key zu speichern > -eine Funkschnittstelle hat die > --genug Reichweite hat > --in einem geschlossenen Auto funktioniert > --zuverlässig "große" Datenmengen fehlerfrei überträgt > -eine Schnittstelle zum Austausch der Public Keys hat > -den aktuellen Zustand des Tores überwacht Du kannst dir das Implementieren der Krypto auch sparen, wenn du eine Smartcard verwendest (musst dann halt dem SC-Hersteller vertrauen). "Deine" zusätzliche Elektronik ist dann effektiv nur ein SC Reader über Funk. Zum einrichten der Schlüssel steckst du die SC an den Laptop, und lädst sie hoch, setzt die PIN etc. Analog bei der Fernbedienung im Auto.
Beitrag #6456923 wurde von einem Moderator gelöscht.
mh schrieb: > -eine Schnittstelle zum Austausch der Public Keys hat Was wäre dir eigentlich lieber? Eine MiroSD karte, die man gegebenenfalls in 2 m Höhe dann anfrimmeln muss oder ein USB Kabel, bei dem man den Schlepptop oder das Smartphone dann kurz mal für das Programmieren irgendwo in der möglicherweise öligen und staubigen Garage platzieren muss? Smartcards haben den Nachteil, dass sie groß sind und die meisten Leute dafür kein Lese- und Schreibgerät am PC haben.
Liebe Diebe schrieb im Beitrag #6456923: > Hängt lieber die Garagentore aus, damit Diebe freie > Abzugsmöglichkeit > haben und so etwas nicht passiert: > https://www.mdr.de/nachrichten/video-460128_zc-fd08c406_zs-950f04ff.html Naja, der Autofahrer hätte das wissen können. Es gab ja auch schon Urteile, wo ein Schusswaffeninhaber flüchtenden Einbrecher in den Rücken schoss und dafür verurteilt wurde. Oder ein anderer Fall, wo das Einbruchsopfer den Einbrecher festband und mit dem Schubkarren transportierte, was das Gericht als menschenunwürdigen Transport aburteilte.
Ja, es ist schon erstaunlich. wie weit Selbstjustiz mitunter geht!
Nano schrieb: > Was wäre dir eigentlich lieber? > > Eine MiroSD karte, die man gegebenenfalls in 2 m Höhe dann anfrimmeln > muss > oder ein USB Kabel, bei dem man den Schlepptop oder das Smartphone dann > kurz mal für das Programmieren irgendwo in der möglicherweise öligen und > staubigen Garage platzieren muss? Mir ist das egal, ich würde es so oder so nicht kaufen. Ich habe ne dumme 8Bit DIP-Schalter Fernbedienung für meine Garage. Ich sehe keinen Grund das zu ändern. Aber denk dran, dass du dann eine Software zum Generiren und Übertragen der Keys entwickeln und mitliefern musst. Und es sollte wohl auch für Menschen die älter als 60 sind zu bedienen sein.
Nano schrieb: > mh schrieb: >> -eine Schnittstelle zum Austausch der Public Keys hat > > Was wäre dir eigentlich lieber? > > Eine MiroSD karte, die man gegebenenfalls in 2 m Höhe dann anfrimmeln > muss > oder ein USB Kabel, bei dem man den Schlepptop oder das Smartphone dann > kurz mal für das Programmieren irgendwo in der möglicherweise öligen und > staubigen Garage platzieren muss? > > > Smartcards haben den Nachteil, dass sie groß sind und die meisten Leute > dafür kein Lese- und Schreibgerät am PC haben. Überzeugt mich nicht. Das Micro-SIM Format ist bereits erfunden und es gibt viele Smartcard-Lesegeräte mit USB. Beispielsweise ein Nitrokey Pro ist effektiv nur ein STM32 der USB<->Smartcard übersetzt und die eigentliche Krypto macht eine OpenPGP Smartcard. Schaltplan, Layout und Code zum Nitrokey sind öffentlich einsehbar und anpassbar. Der Nitrokey kann auch HOTP/TOTP (läuft dann aber glaube ich nicht über die SC). https://en.wikipedia.org/wiki/Nitrokey https://en.wikipedia.org/wiki/OpenPGP_card https://github.com/nitrokey https://github.com/Nitrokey/nitrokey-pro-firmware (GPLv3) https://github.com/Nitrokey/nitrokey-pro-hardware (Schema: CC BY 3.0, PCB: CC BY-SA 3.0) https://www.nitrokey.com/sites/default/files/images/products/NITRO_0003_d.jpg https://static.lwn.net/images/2017/nitro-STM32.jpg https://anarc.at/blog/2017-10-26-comparison-cryptographic-keycards/nitro-pro-backside.jpg
mh schrieb: > Mir ist das egal, ich würde es so oder so nicht kaufen. Ich habe ne > dumme 8Bit DIP-Schalter Fernbedienung für meine Garage. Ich sehe keinen > Grund das zu ändern. Okay, kein Problem. Natürlich gibt's auch Garagen wo, abgesehen vom Auto, nichts wertvolles drin ist und die keinen Zugang zum Haus haben. Aber nehmen wir mal an, es wäre bei dir anders und zum Haus gäbe es einen Zugang von der Garage und am Markt würde es nur diese beiden Varianten geben, also USB oder SD Card, welche würdest du bevorzugen. > Aber denk dran, dass du dann eine Software zum Generiren und Übertragen > der Keys entwickeln und mitliefern musst. Und es sollte wohl auch für > Menschen die älter als 60 sind zu bedienen sein. Ja, schon klar.
mh schrieb: > Aber denk dran, dass du dann eine Software zum Generiren und Übertragen > der Keys entwickeln und mitliefern musst. GnuPG. > Und es sollte wohl auch für > Menschen die älter als 60 sind zu bedienen sein. Wrapper über GnuPG.
vn nn schrieb: > Billige Ausrede, um ungeeigneten Müll als sicher zu verkaufen. Billiger primitiver Angriff auf der unsachlichen Ebene waere hier Dein rhetorisches Stilmittel. Welchen Stakeholder wolltest Du verteidigen? Ist auch ein Stilmittel. Nano und Percy diskutierten bereits ein paar Beitraege weiter unten, was man als Bastler und Theoretiker von den vielen mehr an Mannstunden eines Hersteller erwarten wuerde. Und danach weiter ebenfalls. Das ist jetzt nur sachlich argumentiert.
Nano schrieb: > Mag sein, aber manche Elektronik ist noch viel unsicherer und sie > hinterlässt keine Spuren. > Der Betroffene merkt den Einbruch vielleicht nicht einmal oder nicht > sofort, wenn die anliegende Wohnung, falls in der Garage ein Durchgang > zur Wohnung besteht, mit Bedacht geräumt wird oder die Versicherung > zahlt nicht, weil keine Einbruchspuren vorhanden sind. Und die Versicherung zahlt nicht, weil: kein Einbruch. Da gab es erst letztens eine Gerichtsurteil dazu.
MBenz schrieb: > Und die Versicherung zahlt nicht, weil: kein Einbruch. > Da gab es erst letztens eine Gerichtsurteil dazu. Link?
Nano schrieb: > MBenz schrieb: > >> Und die Versicherung zahlt nicht, weil: kein Einbruch. >> Da gab es erst letztens eine Gerichtsurteil dazu. > > Link? https://www.juris.de/jportal/portal/page/homerl.psml?nid=jnachr-JUNA201003695&cmsuri=%2Fjuris%2Fde%2Fnachrichten%2Fzeigenachricht.jsp
Ben Gunn schrieb: > Nano schrieb: >> MBenz schrieb: >> >>> Und die Versicherung zahlt nicht, weil: kein Einbruch. >>> Da gab es erst letztens eine Gerichtsurteil dazu. >> >> Link? > > https://www.juris.de/jportal/portal/page/homerl.psml?nid=jnachr-JUNA201003695&cmsuri=%2Fjuris%2Fde%2Fnachrichten%2Fzeigenachricht.jsp Danke. Dann muss man in Zukunft beim Vertragsabschluss auch darauf achten, dass neben dem Wort "Aufbruch" auch das Wort "Hacking" abgedeckt wird. Das Problem der Beweisbarkeit hat man dann leider allerdings immer noch. Denn Hacken verursacht kaum Spuren, wenn der Vorgang nicht protokolliert wird.
> Und es sollte wohl auch für > Menschen die älter als 60 sind zu bedienen sein. Es sollte auch Jahrzehnte klaglos ohne Eingriffe funktionieren! Wenn Ihr mich fragt, dann hilft nur ein UND-Glied oder die Reihenschaltung von 2 Kontakten mit 2 völlig unterschiedlichen Systemen. Entweder steht z.B. das Auto auf Induktionsschleifen wenn der Senderknopf gedrückt wird oder die Garage wird nur freigegeben wenn gleichzeitig die Türklingel bimmelt. Chris D. schrieb: > Wenn man aber gar nicht auf das Tor schauen möchte, dann spricht ja > nichts dagegen, dass das Tor noch eine Quittung "Schließe jetzt" > absendet und der Sender eine LED leuchten lässt oder vibriert :-) Ein Holzkeil hat schon manches Tor blockiert ... Bevor eine Endmeldung mit "Erfolg" kommt, ist der Fahrer bestimmt schon weit weg?
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.