Forum: Mikrocontroller und Digitale Elektronik Wie funktioniert das mit dem Wechselcode bei Funk-FB


von Thomas (kosmos)


Lesenswert?

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?

von Christoph Kessler (db1uq) (Gast)


Lesenswert?

"keyless door control", "keyless entry"

von Benedikt K. (benedikt)


Lesenswert?

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.

von Frank (Gast)


Lesenswert?

Ü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.

von Benedikt K. (benedikt)


Lesenswert?

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...

von Thomas (kosmos)


Lesenswert?

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.

von Benedikt K. (benedikt)


Lesenswert?

Ob Tabelle oder nicht ist ja auch egal, das Ergebnis ist das selbe: Es 
werden abhängig vom aktuellen Stand verschiedene Codes erzeugt.

von Profi (Gast)


Lesenswert?

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.

von hand sieter (Gast)


Lesenswert?

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)

von DS aus W (Gast)


Lesenswert?

@ 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

von Wolfgang H. (wulfinator)


Lesenswert?

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

von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


Lesenswert?

Geht´s auch ohne Ausrufezeichen?!

von genau (Gast)


Lesenswert?

Warum hat er nicht auch nach "mfg" kein Ausrufezeichen gesetzt?

von Hagen R. (hagen)


Lesenswert?

>>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

von Unfuture (Gast)


Lesenswert?

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

von Matthias (Gast)


Angehängte Dateien:

Lesenswert?

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.

von JojoS (Gast)


Lesenswert?

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...

von Wolfgang H. (wulfinator)


Lesenswert?

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!

von Dennis H. (hoh)


Angehängte Dateien:

Lesenswert?

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?

von Dennis H. (hoh)


Lesenswert?

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!

von Dennis H. (hoh)


Lesenswert?

Ok, Fragen erledigt....

Zum auslesen wird DWTR 6k/8k benötigt...

Danke fürs lesen ;-)

Gruß

von Alt (Gast)


Lesenswert?

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).

von Harald W. (wilhelms)


Lesenswert?

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

von Max (Gast)


Lesenswert?

Bei meinem Opel muss man nachdem man de Motor gestartet hat (30 secs 
Zeit) auf einen der Knöpfe drücken....

von Herr M. (herrmueller)


Lesenswert?

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);-)

von Alt (Gast)


Lesenswert?

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.

von Alt (Gast)


Lesenswert?

Irgendwas stimmt mit den EEPROM Daten nicht, es wird weder beim Schalten 
noch beim Wegnehmen der Spannung geschrieben - wie kommt also der 
Zustand hinein?

von ET_Stud (Gast)


Lesenswert?

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.

von Alt (Gast)


Lesenswert?

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.

von Frank M. (aktenasche)


Lesenswert?


von Spicer L. (treki) Flattr this


Lesenswert?

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
von Spicer L. (treki) Flattr this


Lesenswert?


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
Noch kein Account? Hier anmelden.