Wollte mal fragen wie das mit dem Wechselcode funktioniert, damit der Empfänger nicht 2mal auf den gleichen Code reagiert und somit eine Aufzeichnung der Verbindung missbraucht werden kann. Ich nehme mal an das es so geht. Die Fernbedienung sendet einen Code an den Empfänger dieser sendet eine Bestätigung zurück an den Sender dadruch wechseln beide ihren Code auf den nächsten der sich laut einer abgespeicherten Formel oder Liste ergibt. Oder überträgt der Empfänger einen neuen Code verschlüsselt an den Sender damit beim nächsten mal dieser zur Anwendung kommt? Ist das nicht etwas fehleranfällig falls der Empfang der Bestätigung gestört wird? Gibts da ein bestimmten Stichwort wonach ich da googeln könnte?
Meistens läuft das nur in eine Richtung: Der Sender sendet das Signal, wechselt dann den Code, der Empfänger ebenfalls. Beide haben quasi eine Tabelle in welcher Reihenfolge die Codes drankommen. Das ganze funktioniert wunderbar, solange nicht der Sender mehrmals den Code wechselt, der Empfänger das Signal aber nicht empfängt und daher bei dem alten Code stehen bleibt. Meistens ist der Empfänger daher etwas tolerant und erkennt das und synchronisiert sich dann wieder neu, wenn die folgenden Codes alle in der richtigen Reihenfolge kommen. Vermutlich gibt es noch dutzende andere Verfahren, von denen einige ein Firmengeheimnis bleiben um das verfahren sicher zu machen.
Über eine "Codetabelle" funktioniert das sicherlich nicht, da eine "Codetabelle" irgendwann alle Codes durch hat und dann das System unbrauchbar währe. Der Empfänger als auch der Sender verfügen über einen Zähler ,der bei jedem gesendetem und empfangenen Signal incrementiert wird. Der Zählerstand wird vom Sender über einen Algorithmus mit einem bestimmtem Code zusammen verschlüßelt. Der Empfänger macht dann genau das gegenteil. Falls der Empfänger einmal ein Signal "verpasst" hat, dann macht er folgendes: 1) Signal mit aktuellem Zählerstand entschlüßeln. 2) -Falls code nicht übereinstimmt, dann Zähler inkrementieren und beginne wieder bei 1) - Falls Code übereinstimmt ,dann Zähler inkrementieren. Wenn der Auslöser Zehnmal betätigt wurde ,ohne das ser Empfänger das Signal empfangen konnte ,dann muß er beim elften mal 10 Schlüßel durchprobieren um den letzten zu finden.
Frank wrote: > Über eine "Codetabelle" funktioniert das sicherlich nicht, da eine > "Codetabelle" irgendwann > alle Codes durch hat und dann das System unbrauchbar währe. > > Der Empfänger als auch der Sender verfügen über einen Zähler ,der bei > jedem gesendetem und > empfangenen Signal incrementiert wird. Auch ein Zähler läuft irgendwann mal über, und fängt wieder von vorne an...
angenommen da ist wirklich ne Tabelle drin dann müssten die Teile ja schon nen größeren Speicher eingebaut haben da ja einige Millionen oder gar Milliarden Codes versprochen werden.
Ob Tabelle oder nicht ist ja auch egal, das Ergebnis ist das selbe: Es werden abhängig vom aktuellen Stand verschiedene Codes erzeugt.
Schau mal bei Microchip die HCS-Reihe an. Deren Verfahren heißt KeeLoq, da gibt es viel zu finden beim Google. Finde ich aber nicht gerade sehr sicher. Es gibt noch unzählige andere Verfahren von anderen Herstellern.
das mit der tabelle ist quatsch, da steht ein stück code drin, das den code auf anfrage generiert. das heißt dann scrambler. das kann man auch in hardware gießen und bekommt z.b. auf ein takt-signal einen neuen code. wenn du ein beispiel mit code suchst, dann schau dir mal den anhang zu den SATA specs an. die machen da sowas (aber aus einem anderen grund)
@ Profi : Warom sollte das code hopping-Verfahren unsicher sein ? Worin begründet sich der Verdacht ?? Diese Verfahren beruhen auf einem Algorithmus, der für eigene Applikationen auch von Microchip erhältlich ist. Einfachere, selbst gebastelte, Verfahren findet man im INET. Gruss Dietmar
Möglich wäre auch folgende Variante: Sender und Empfänger haben den selben Schlüssel! Der Sender sendet eine Reihe von Zufallszahlen und danach die Zufallszahlen verschlüsselt (zb DES)! Der Empfänger verschlüsselt ebenfalls die Zufallszahlen und vergleicht sie dann mit den Empfangenen! Somit wäre eine Authentisierung möglich: Der Empfänger weiß nun, dass der richtige Sender zu ihm spricht! Bei dieser Variante müsste man nur mehr sicher gehen, dass nicht öfters die selben Zufallszahlen empfangen werden, sonst wäre ein mithören und wiedergeben eines Angreifers möglich! Einfacher ist es bei einer bidirektionalen Verbindung! Da liefert einfach die Slaveseite die Zufallszahlen nach einem Request! Am Besten wäre es verschiedene Schlüssel für die verschiedenen Funktionen zu verwenden! (schlüssel auf, schlüssel zu, ...) somit müssen keine Steuerdaten mehr übertragen werden! Die Information steckt in den verschlüsselten Zufallszahlen die aber ohne Schlüssel nichts wert sind! mfg
Warum hat er nicht auch nach "mfg" kein Ausrufezeichen gesetzt?
>>Bei dieser Variante müsste man nur mehr sicher gehen, dass nicht öfters >>die selben Zufallszahlen empfangen werden, sonst wäre ein mithören und >>wiedergeben eines Angreifers möglich! Das erübrigt sich wenn man ein sicheres Verschlüsselungsverfahren verwendet. Dann kann man statt Zufall gleich einen Zähler benutzen. Beides muß gegen Brute Force Attacken, speziell Rainbow Tables resistent sein, also minimal 128 Bits groß. Und da ist das Problem, denn man benötigt pro Kommando 256 Bits minimal. Beim KeyLoq hat man dies versucht zu reduzieren indem man nur 64Bit SIcherheit garantiert, Counter viel viel kürzer ist und als Prüfsumme nur einen Teil sendet. Ein zweites, nicht unerhebliches Problem, entsteht bei der Serialisierung der Empfänger. Diese müssen ja mit dem gleichen Schlüssel des Senders arbeiten und der muß erstmal zum Empfänger übertragen werden. Und was passiert wenn der Sender ausser Reichweite des Empfängers die nächsten x Codes sendet ? und somit die Synchronisation mit dem Empfänger verloren geht ? auch das muß berücksichtigt werden. Gruß Hagen
Hi, >Und was passiert wenn der Sender ausser Reichweite des >Empfängers die nächsten x Codes sendet ? und somit die Synchronisation >mit dem Empfänger verloren geht ? auch das muß berücksichtigt werden. genau deswegen ist doch der Code in einen FestBitAnteil und einen variablen BitAnteil unterteilt! Der FestBitAnteil dient zum erkennen, ob der Schlüssel überhaupt zur Schloss-Serie passt und ob Aufgeschlossen oder z.B. ein neuer Schlüssel angelernt werden soll. Insofern ist ein kleiner Teil des FestBitAnteil in wirklichkeit bedingt variabel, da hier noch Steuerungsfunktionen übertragen werden können. Der variable BitAnteil dient in der Regel dazu, mit einem zufällig initialisierten Zählerstand + x Abweichung sicherzustellen, dass mit einer Wahrscheinlichkeit von 1 - (x / AnzahlMöglichkeiten) kein anderer Schlüssel passt. Wenn der Schlüssel keinen Sync mehr hat und die Sicherheit durch einen stetig laufenden Zähler realisiert wird, kann nur ein anderer - noch im Sync befindlicher Schlüssel - den anderen Schlüssel wieder anlernen. Oder es gibt eine Anlern-Taste am Empfänger. Wenn sich der Sender durch mehrmaliges betätigen selbst wieder synchronisiert, ist nicht der Zählerstand das Kriterium, sondern eine Art einmalige Seriennummer also eigentlich der FestBitAnteil) und der Zähler hat nur die Funktion, ein profanes Kopieren des zuletzt gesendeten Codes zu verhindern. In dem Fall muss der Zählraum auch nicht so groß sein, da würden wohl 16 Bit reichen, da wohl kein normaler Anwender mehr als 65000 Schließzyklen in seinem Leben tätigt. Durch eine vernünftige symmetrische Verschlüsselung wird sowieso die kleinste BitÄnderung im Klartext zu einer mit Hash-Funktionen vergleichbaren großen und nicht direkt nachvollziehbaren Änderung im Ciphertext führen. Es gibt beide Systeme und noch viele andere, die eigentliche Schwachstelle ist - wie schon gesagt wurde - die schwache symmetrische Verschlüsselung und die Tatsache, dass die Firmen ihre Verschlüsselungsalgorithmen nicht veröffentlichen. Security by Obscurity -> war schon immer schlecht! Unfuture
Genau das Thema hat mich auch mal interessiert. Mein alter Ford Fiesta hatte eine IR-Fernbedienung und ich habe den Code mal versucht auszulesen um etwas herauszufinden. Im Anhang seht ihr die einzelnen Bits. Ich habe vier mal auf die Fernbedienung gedrückt. Aber seit dem ging die Fernbedienung nicht mehr beim Auto! Warum? ich habe einfach zu oft draufgedrückt und jetzt erwartet der Empfänger einen älteren Code. Ich schätze mal ich habe höchstens 100mal draufgedrückt. P.S. Weis wer wie ich Schlüssel und Auto wieder Synchronisieren kann? Falls jemand denkt er kann jetzt das Auto klauen: Ich habe erstmal den Empfänger abgestepselt.
Beim Mercedes hatte ich das auch mal ausprobiert, den Code vom Schlüssel mit meiner Casio Armbanduhr mit FB gespeichert. Einmal konnte man dann die Tür öffnen, beim nächsten mal natürlich nicht mehr. Bei zuviel ärgern des Empfängers war dann auch irgendwann mal die Sync futsch. Lt. Betriebsanleitung musste man dann bei gedrückter Türöffnertaste die FB betätigen, dann passte das wieder. An den Knopf kommt man nur im Wagen, man muss ihn also evtl. einmal mechanisch aufschliessen. Über die FB kann man auch die Fenster zumachen, das geht aber aus Sicherheitsgründen nur mit verminderter Reichweite. Also selbst in so einem 'simplen' Schlüssel steckt ne Menge know-how drin...
Also ich möchte DES schon als sicher bezeichnen und die Mindestlänge ist dabei 8Byte, also 64Bit. Der Nachteil bei festen bzw. erratbaren Bestandteilen der Nettodaten sinkt die Sicherheit der Verschlüsselung! Mit der von mir beschriebenen Variante benötigt man auch keine Synchronisierung, so lange sich der Empfänger die letzten Daten merkt und für die nächsten Transaktionen als ungültig erklärt (es müsste theoretisch eine 2Byte Checksumme über die Daten genügen, die dann 1-2Tage gespeichert werden) Genauso könnte es der Sender machen und Zufallszahlen die dann diesen Checksummen entsprechen verwerfen. Somit wäre man gegen Mithören resistent und es würde dennoch jedesmal funktionieren. Ich werde mich mal wegen diesen Rainbow Tables schlau machen. -> noch nie gehört! Wolfgang Einen speziellen Dank an "Travel Rec." und "genau (Gast)"! Von Leuten wie euch lebt ein Forum, macht Spaß hier zu schreiben!
Hab mir bei eBay son ne INCA-Pro zum basteln geschossen und mal zerlegt! Siehe Anhang! Hab mittels Oszi mal so ein Code (abgegriffen vom µC-Pin) aufgezeichnet. Ich hab folgende Vermutung: Der Sender sendet bei Betätigung - aktueller Code zum identifizieren -"Auftrag" Welche Taste gedrückt wurde - neuer Code für nächste Identifizierung. Dieser wird dann ins EEPROM geschrieben, falls Spannungsausfall. Aufgebaut mit 8-Bit µController ( ELAN EM78P156NPJ ) mit 1k EEPROM Hat jemand ne Idee, ob und wie man den µC auslesen könnte?
Bei dem µC handelt es sich um ein OTP. Wenn das Häckchen "Protect" in der Brennsoftware EMC DWRITER nicht gesetzt wurde, sollte es gehn!
Ok, Fragen erledigt.... Zum auslesen wird DWTR 6k/8k benötigt... Danke fürs lesen ;-) Gruß
Da ich zum Controller anstelle eines Datenblatts auf Anhieb diese Seite gefunden habe.. http://www.emc.com.tw/eng/index.asp Der Mikrocontroller ELAN EM78P156NPJ ist in derzeit (bekannte Online-Auktionsplattform) erhältlichen Nachrüst-Sets für PKW Zentralverriegelung immer noch enthalten. Eeprom "ATMEIL 12 93C46 PW27 D"(!). Mit ca. 15 Euro ausbeuterisch billig, entsprechend stinken die Kabel. Vier Relais für Auf/Zu, Licht, Hupe. Die Steuerung merkt sich den Zustand der Aktoren (und signalisiert dann nur). Der Sender hat 4 Tasten: Schloß zu, Schloß offen, Lautsprecher aus, Glocke. Schließen/Öffnen: - Schließen blinkt/hupt einmal - Öffnen blinkt zweimal. - Aktoren werden für eine halbe Sekunde geschaltet. Glocke: - schaltet "Siren (Pink)" ein und blinkt "Flash light (brown)" im Sekundentakt. Lautsprecher aus: - pulst Licht für 140 ms, wenn zu - bricht Glocke ab - schließt, wenn offen und Glocke aus Zwei der vier Aktoren haben 2 Schalter, mit denen das Öffnen/Schließen aller ausgelöst wird. Ob da wirklich "Keeloq" drin ist, habe ich nicht geprüft. Die Aktoren schaffen etwa 25 N über 2 cm und bestehen vermutlich im Wesentlichen aus einer Kunststoffzahnstange. Das Gehäuse ist verschweisst. Mein Netzteil zeigt bei 12 V 0.01 A Stromaufnahme (keine Lust zu messen).
Matthias schrieb: > P.S. Weis wer wie ich Schlüssel und Auto wieder Synchronisieren kann? Bei meinem Peugeot ist die Prozedur in der Bedienungsanleitung beschrieben; hast Du in Deiner schon mal nachgesehen? Gruss Harald
Bei meinem Opel muss man nachdem man de Motor gestartet hat (30 secs Zeit) auf einen der Knöpfe drücken....
Harald Wilhelms schrieb: > Matthias schrieb: > >> P.S. Weis wer wie ich Schlüssel und Auto wieder Synchronisieren kann? > > Bei meinem Peugeot ist die Prozedur in der Bedienungsanleitung > beschrieben; hast Du in Deiner schon mal nachgesehen? > Gruss > Harald Ich vermute stark, dass er das Problem in den letzten 6 Jahren lösen konnte (falls er das Auto noch hat);-)
Ich habe doch ein wenig weitergeforscht. Man verzeihe mir, dass ich den Thread kapere, aber jemand, der nach der Controllerbezeichnung sucht, wird daran interessiert sein, dass KEIN Keeloq o.Ä. genutzt wird und deshalb eine replay attack ausreichen würde, um das Auto zu öffnen. Das Produkt ("Top central door lock with remote", "central lock system with remote") kommt via Eba* aus Essen, hat kein aufgebrachtes CE Zeichen (aber Kontaktdaten des Verkäufers), die Frequenz steht auch nicht drauf (Sender HS2240 & 433 MHz "Oszillator" & 3x3V Knopfzelle, also wie bei vielen Funksteckdosen). Der Encoder ist auch bekannt als PT2240 (wird das automatisch erkannt? Wenn nein: http://www.mikrocontroller.net/part/PT2240). Hier ein Decoder in Bascom: www.mikrocontroller.net/topic/139002. Hier Notizen zur "Untersuchung": Annahme 1 - short high long low (100) 0 - long high short low (110) 101100001101100010011110 101100001101100010011110 Folgepakete stimmen überein. Frame: 27 ms 24 Bit (Keeloq 64 bit) Bit: 1.126 ms Kurz: 257-293 µs Lang: 830-869 µs Kurzer Stop-Puls Dieselbe Taste, andere Zeit 101100001101100010011110 -> identisch: kein Keeloq! Sender haben dieselbe Nummer auf dem Aufkleber, das ist aber nicht die Seriennummer, sie senden unterschiedliche IDs: Alle Tasten Schlie A 10110000 11011000 10011110 B 01100100 10111000 10011110 Öffnen A 10110000 11011000 10011101 B 01100100 10111000 10011101 Stumm A 10110000 11011000 10011011 B 01100100 10111000 10011011 Alarm A 10110000 11011000 10010111 B 01100100 10111000 10010111 Die letzten Bits gehören offenbar der Funktion. Evtl. sollte man die Bits invertieren, dann ist es "logischer". Der Empfänger hat eine AGC und braucht eine Anzahl von Paketen um sich darauf einzustellen (vorher sammelt er alles ein, was er kriegen kann). Bei Funkstille ist dann erstmal 200 ms echte Stille [siehe decoder thread, sync]. Das letzte Paket ist nicht unbedingt vollständig (sendet stur nach Zeit?). Etwa 1 s nach Einschalten wird mit dem SPI EEPROM gesprochen (EN active high). 2 us clock pulse, 11 µs Bitzeit DI und DA sind zusammengelegt Der EEPROM ist folgendermaßen konfiguriert: The AT93C46 provides 1024 bits of serial electrically erasable programmable read- only memory (EEPROM), organized as 64 words of 16 bits each (when the ORG pin is connected to VCC). 26 bit / Paket: 1 Start 2 OpCode 6 Adress 1 Dummy 16 Data Praktisch werden jedoch nur 25 Bit übertragen. Ob das Dummy bit wegfällt? Wird ein anderer Adressierungsmodus genutzt? Hier die Daten, die Bits entsprechend gruppiert: Geschlossen: S Op Addr Data 1 10 000110 0000 0000 0000 0010 1 10 000110 1101 1011 1110 0100 1 10 001000 0011 0000 1101 1011 1 10 001000 0110 0011 1111 0000 1 10 001010 0000 0111 0000 0011 1 10 001010 0111 0000 1111 1111 1 10 001100 1111 1111 1111 1111 Offen: S Op Addr Data 1 10 000110 0000 1101 1000 0110 1 10 000110 1101 1011 1110 0000 1 10 001000 0011 0000 1101 1011 1 10 001001 0110 0011 1111 0000 1 10 001010 0000 1111 0000 0011 1 10 001010 0010 0000 1111 1111 1 10 001100 0111 1111 1111 1111 Es müsste eigentlich noch ein Adressbit genutzt sein, sonst machen unterschiedliche Daten keinen Sinn. Evtl. verhält sich der IC aber anders, als das Original. Man könnte mal den ganzen Speicher auslesen, aber der Nutzen ist nicht so groß.. Ich wollte nur rausfinden, ob man die IDs der Sender wiederfindet.
Irgendwas stimmt mit den EEPROM Daten nicht, es wird weder beim Schalten noch beim Wegnehmen der Spannung geschrieben - wie kommt also der Zustand hinein?
Interessant ist das hier: http://www.eurica.ru/sound/HCS300.pdf Da steht teilweise drinnen, wie beispielsweise Microchip Keeloq funktioniert bzw. wie das mit der Synchronization abläuft.
Es gibt auch Code von Atmel für rolling code / code hopping. Keeloq ist anscheinend teils knackbar: http://en.wikipedia.org/wiki/KeeLoq http://www.pittnerovi.com/jiri/hobby/electronics/keeloq/index.html (hier Keeloq Code) Ich schrieb oben, dass das letzte Paket unvollständig sein kann: der Sender ist möglicherweise für die Dauer des Tastendrucks aktiv, anstatt eine zeitlang zu senden.
Findet Ihr nicht, es wäre an der Zeit, einen opensource Standard zu entwickeln/einzuführen? Man denke an die vielen Raspberry und Atmel Fans, welche keine pauschal Lösung wollen! Habe 6 Jahre nach diesem Thread das gleiche Problem. ....und ich will nicht jedes Gerät vom gleichen Hersteller kaufen!
:
Bearbeitet durch User
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.