eKey Fingerscanner per RS485 auslesen: Protokollanalyse

[tuxedo]

Echt krasser sch??ß ... Ich glauh nur ich werde das noch 1-2x lesen müssen bevor ich's komplett verstanden habe.

[UweH]

Zum Thema "Wie extrahiert man Finger und User aus dem Datenstrom" hier die (noch nicht ganz schöne, aber praktikable) Lösung:
- Mittels StartOfFrame (0x02) und Längeninfo sammle einen kompletten Frame auf.
- Unstuffing: Ersetze innerhalb des Frames alle aufgeblasenen Daten durch die originalen:
3F 41 --> 02
3F 81 --> 03
3F C1 --> 3F
Durch das Ersetzen verkürzt sich der Frame jeweils um ein Byte, die Daten rutschen nach links auf.
- Prüfe auf exakte Länge 47.
- An Index 17 steht der FingerHash.
- Vergleiche den FingerHash mit Konstante/Tabelle, um Aktion zu bestimmen.

Die Bestimmung der FingerHashes (also Vorausberechnen der erwarteten Werte) geht mit folgendem Code. Vorsicht, es gibt Mehrdeutigkeiten, die sich nur durch geschickte Wahl der User-Zuordnung vermeiden lassen. Bei Privatanwendern mit kleiner 10 Usern sollte das keine wirkliche Einschränkung sein.

#include <stdio.h>

int nUser;
int nFinger;
int nFingerZeroBased;
int nFingerHash;
 
#define INSTALLATIONS_KONSTANTE 0x7F

int main(void)
{
    printf("Willkommen zum EKEY-Rechner\n");
    
    for (nUser=1; nUser<=99; nUser++) {
        for (nFinger=1; nFinger<=10; nFinger++) {
            nFingerZeroBased=nFinger-1;
            
            nFingerHash = INSTALLATIONS_KONSTANTE;
            if (nUser & 0x01) nFingerHash ^= 0x5B;
            if (nUser & 0x02) nFingerHash ^= 0xB6;
            if (nUser & 0x04) nFingerHash ^= 0xE9;
            if (nUser & 0x08) nFingerHash ^= 0x57;
            if (nUser & 0x10) nFingerHash ^= 0xAE;
            if (nUser & 0x20) nFingerHash ^= 0xD9;
            if (nUser & 0x40) nFingerHash ^= 0x37;

            if (nFingerZeroBased & 0x01) nFingerHash ^= 0x6D;
            if (nFingerZeroBased & 0x02) nFingerHash ^= 0xDA;
            if (nFingerZeroBased & 0x04) nFingerHash ^= 0x31;
            if (nFingerZeroBased & 0x08) nFingerHash ^= 0x62;
            
            printf("User %i Finger %i ergibt FingerHash 0x%X\n", nUser, nFinger, nFingerHash);
        }
    }
    return 0; 
}

[UweH]

Rücksetzen auf Werkseinstellungen setzt Kopplung zurück

In anderen Dokumenten (z.B. ekey Doc 132) steht dagegen ausführlich beschrieben, wie man das System auf Werkseinstellungen zurücksetzen kann. Wobei mir nicht klar ist, ob das auch die Kopplung der Komponenten betrifft.

Für den ekey home ist in der Doku http://www.ekey.net/downloads?downlo..._web_ID171.pdf beschrieben, was beim Rücksetzen auf Werkeinstellungen passiert:
- Alle Finger werden unwiederbringlich gelöscht.
- Der Sicherheitscode wird auf 99 gesetzt.
- Steuereinheit und Fingerscanner verlieren ihre Koppelung.
- Die Relaisschaltzeiten werden auf 3 s gesetzt.

[UweH]

Physical-Layer-Themen

Beim Versuch, die RS485-Auswertung in einen Controller zu gießen, gibt's Fallstricke:
(1) Die Baudrate. Nominal sind das zwar 115,2kBaud, aber eine gewisse Toleranz ist ja erlaubt. Wenn man von den Gegebenheiten der Hardware an bestimmte Baudraten gebunden ist, kann das ins Auge gehn: Ein AVR mit 8 MHz Quarz kann als "passendste" Baudrate (DBR=1, UBRR=8) 111.1k, was 3.5% zu langsam ist und eigentlich passen sollte. ABER: Der ekey-Master ist schneller als nominal, etwa 117k. Ergebnis: Der AVR interpretiert das Stopp-Bit als letztes Datenbit --> Müll. Abhilfe: 16 MHz Quarz, DBR=1, UBRR=16. Damit kommt man auf 117,6 kBaud, und die Kommunikation klappt.
(2) RS485-Pegel im Idle-Zustand. Sendet kein Knoten, liegen beim ekey beide Leitungen auf der gleichen Spannung. Der MAX485 hat - wenn ich das Datenblatt richtig verstehe - zwischen -0.2V und +0.2V einen undefinierten Bereich. In EIA-485 ? Wikipedia wird daher ein Bias-Netzwerk empfohlen, um definierte Pegel zu bekommen. Mein "Unter-Drei-Euro-RS485-auf-USB-Konverter" hat einen MAX485 verbaut und erkannte zwischen den Frames oft eine (real nicht vorhandene) 0x00, manchmal wurde auch das darauffolgende StartOfFrame (0x02) verschluckt. Abhilfe: Bias-Netzwerk einbauen. Oder anderen Receiver verwenden. Kann mal jemand schaun, welche auf dem ekey verbaut sind?

[Dirk42]

Beim Versuch, die RS485-Auswertung in einen Controller zu gießen, gibt's Fallstricke:

Damit würdest Du ja quasi "nur" den ekey UDP Konverter nachbauen - und hättest Kosten für Controller und co. Einfacher wäre doch, einen der billigen UDP-USB Ports zu verwenden mit denen Ihr testet und den an einen schon vorhandenen RasPi, WireGate oder so anzuschließen?

Ich weiß immer noch nicht welchen ekey ich bestellen werde. Eine Idee ist, dass die Hauptfunktion "Tür auf" komplett und alleine von der ekey Steuerung übernommen wird. Die Info welcher Nutzer die Tür geöffnet hat wird dann nur zusätzlich für Komfortfunktionen genutzt a la "Dirk ist zuhaus, mach schon mal das Radio an". Wobei es auf Dauer vielleicht auch ganz nett wäre, mit anderen Fingern andere Funktionen zu schalten wie "Törchen auf", "Briefkasten öffnen" etc. Das spricht für eine Steuerung mit zwei Relais: Relais 1 steuert wie gehabt die Haustür, Relais 2 ist nicht angeschlossen - die x Funktionen die darüber gesteuert werden sollen übernimmt mein WireGate nach Auswertung der Person / Finger.

[UweH]

Damit würdest Du ja quasi "nur" den ekey UDP Konverter nachbauen - und hättest Kosten für Controller und co. Einfacher wäre doch, einen der billigen UDP-USB Ports zu verwenden mit denen Ihr testet und den an einen schon vorhandenen RasPi, WireGate oder so anzuschließen?

Du meinst den RS485-USB-Konverter, z.B. am Raspberry etc. anschließen? Wäre auch eine Lösung. Der Raspberry ist mir im Moment für solche Spielchen aber zu instabil, der hängt sich alle paar Tage auf (nur wenn er Webradio spielt). Das "UDP" brauchts dann nicht, dass ist ja das Ethernet-Protokoll, in das der ekey (RS485-zu-)UDP-Konverter wandelt.

In einen AVR wandert die Auswertung bei mir deswegen, weil die meine "Standard-Knoten" sind. Hab eine eher verteilte Anordnung mit über 10 Knoten. Der "Türknoten" soll dann alles türspezifische abhandeln (ekey, Reedkontakt, Riegelschaltkontakt, Tür-Licht).

Ich weiß immer noch nicht welchen ekey ich bestellen werde. Eine Idee ist, dass die Hauptfunktion "Tür auf" komplett und alleine von der ekey Steuerung übernommen wird. Die Info welcher Nutzer die Tür geöffnet hat wird dann nur zusätzlich für Komfortfunktionen genutzt a la "Dirk ist zuhaus, mach schon mal das Radio an". Wobei es auf Dauer vielleicht auch ganz nett wäre, mit anderen Fingern andere Funktionen zu schalten wie "Törchen auf", "Briefkasten öffnen" etc. Das spricht für eine Steuerung mit zwei Relais: Relais 1 steuert wie gehabt die Haustür, Relais 2 ist nicht angeschlossen - die x Funktionen die darüber gesteuert werden sollen übernimmt mein WireGate nach Auswertung der Person / Finger.

Ist halt die Frage, ob es störend ist, dass bei "Garage auf" auch die Haustür mit entriegelt. Schöner wärs schon separat. Bei mir gehts jetzt halt nur kombiniert. Vielleicht kann man ja die 1-Relais so umbauen, dass die Software meint, sie läuft auf 2-Relais :-) Also kauf du mal die 2-Rel, um die Unterschiede anzuschaun :-))

[Dirk42]

Ist halt die Frage, ob es störend ist, dass bei "Garage auf" auch die Haustür mit entriegelt. Schöner wärs schon separat. Bei mir gehts jetzt halt nur kombiniert. Vielleicht kann man ja die 1-Relais so umbauen, dass die Software meint, sie läuft auf 2-Relais :-) Also kauf du mal die 2-Rel, um die Unterschiede anzuschaun :-))

Jepp - meine Tür geht von alleine einen kleinen Spalt auf, wenn das Fuhr öffnet. Es wäre unsmart, wenn ich dann jedes Mal die Haustür wieder zuziehen muss, nur weil ich die Klappe zum Gewölbekeller entriegeln will...
Die Preispolitik von ekey steht der 2-Relais-Variante etwas im Weg, der Mehrpreis für das zweite Relais ist echt heftig.

[UweH]

Es wäre unsmart, wenn ich dann jedes Mal die Haustür wieder zuziehen muss, nur weil ich die Klappe zum Gewölbekeller entriegeln will...

Man könnte auch in Reihe zum ekey-Relais ein weiteres schalten. Im Ruhezustand geschlossener Kontakt, so dass bei Ausfall der Basteleien die Tür-Funktion nicht beeinträchtigt ist. Und wenn wir den Finger fürs Gewölbe erkennen, dann blitzschnell das Relais anziehen --> Tür bleibt zu. Somit wären mit 15 Euro Bauteilkosten sowohl der UDP-Konverter als auch der heftig teure zweite Kanal eingespart.

[Dirk42]

Das wäre mir zu "heiß": Die Türöffnung möchte ich möglichst weit von anderen Funktionen trennen. Ich achte vielleicht noch darauf, dass die Haustür auch aufgegangen ist - weil grad irgendwas hängt, das WireGate gestört wurde oder was auch immer. Aber das kann ich sicher meinen Nachbarn nicht beibringen, die nur mal im Urlaub nach Haus und Hof schauen sollen. Da sehe ich den Mehrpreis für das zweite Relais das geringere Übel...

[UweH]

Aber das kann ich sicher meinen Nachbarn nicht beibringen

Ja das ist wohl wahr. Das ganze sollte noch bedienbar sein und einigermaßen narrensicher funktionieren, auch wenn der Owner mal 6 Wochen auf Reha etc. ist und ausgerechnet dann irgendeine Komponente versagt. Mein Ansatz: Einfach den Stecker ziehen und wie früher den Schlüssel benutzen, falls die Elektronik spinnt.

Zur Erkennung des Falls "Tür entriegelt aber nicht geöffnet" hab ich zusätzlich zum "Tür offen"-Reed einen Riegelschaltkontakt eingebaut. Der Vollausbau könnte dann sein, Mails rumzuschicken mit dem Inhalt "Vorsicht, die Haustür ist nur angelehnt. Bitte mal nachschauen." Oder den netten nachschauenden Nachbarn akustisch zu informieren "Bitte Haustür zuziehen". Ich weiß, man kann's auch übertreiben

[Dirk42]

Ja das ist wohl wahr. Das ganze sollte noch bedienbar sein und einigermaßen narrensicher funktionieren, auch wenn der Owner mal 6 Wochen auf Reha etc. ist und ausgerechnet dann irgendeine Komponente versagt.

Ersetze "Reha" durch "Urlaub in der Karibik", das klingt sympathischer

Anderer Ansatz, damit man nur ein Steuergerät mit einem Relais braucht (es gibt ja nicht alle mit 2-3 Relais): Das ekey Steuergerät steuert die Tür nicht direkt an, die Erfolgsmeldung per UDP wird in HS, WireGate, RasPi ausgewertet, auf Funktion / Zuordnung geprüft - und die Tür dann vom HS/WG über einen IO geöffnet.
Die Frage ist: Kommt das Signal per UDP schnell genug & klappt die Auswertung schnell genug oder nervt die Wartezeit den Anwender?
... und ich denke die ganze Zeit darüber nach, mal einen Thread zu starten über die Sicherheitsrisiken wenn HS, Android Apps und co die Tür öffnen können...

[2ndsky]

Anderer Ansatz, damit man nur ein Steuergerät mit einem Relais braucht (es gibt ja nicht alle mit 2-3 Relais): Das ekey Steuergerät steuert die Tür nicht direkt an, die Erfolgsmeldung per UDP wird in HS, WireGate, RasPi ausgewertet, auf Funktion / Zuordnung geprüft - und die Tür dann vom HS/WG über einen IO geöffnet.
Die Frage ist: Kommt das Signal per UDP schnell genug & klappt die Auswertung schnell genug oder nervt die Wartezeit den Anwender?
... und ich denke die ganze Zeit darüber nach, mal einen Thread zu starten über die Sicherheitsrisiken wenn HS, Android Apps und co die Tür öffnen können...

Ich mache das so mittels smarthome.py und da gibt es keine spürbare Wartezeit. Sobald der ekey grün leuchtet geht entweder Haustüre, Garagentor oder -türe auf. Das Relais am ekey ist unbelegt. Ist aber natürlich eine Sicherheitsfrage, ob man das möchte oder nicht. Die Diskussion darüber sollte man aber wirklich in einem anderen Thread machen bzw. gab es auch schon zur Genüge hier im Forum.

[UweH]

Das ekey Steuergerät steuert die Tür nicht direkt an, die Erfolgsmeldung per UDP wird in HS, WireGate, RasPi ausgewertet, auf Funktion / Zuordnung geprüft - und die Tür dann vom HS/WG über einen IO geöffnet.
Die Frage ist: Kommt das Signal per UDP schnell genug & klappt die Auswertung schnell genug oder nervt die Wartezeit den Anwender?

Wie schnell die o.g. Teile sind, kann ich nicht beurteilen, aber in einen AVR gegossen braucht's keine 10 Millisekunden vom "Scanner sendet Finger erkannt" bis "Relais wird bestromt". Was viel mehr stört, sind die Detektionszeit des ekey und die Aufschließzeit (in meinem Fall ein GU secury). In Summe steht man da schätzungsweise 3 bis 5 Sekunden vor der Tür, bevor sie endlich aufgeht. Ich hätt mir das schneller vorgestellt, wie beim Auto mit der Funkfernbedienung: Drück-Klack-Auf in einer halben Sekunde.

Das Problem der obigen Funktionalität sehe ich weniger in der Angreifbarkeit (Terrassentür aufhebeln ist das viel wahrscheinlichere Angriffsszenario), als viel mehr in der Zuverlässigkeit. Je mehr Komponenten und Schnittstellen beteiligt sind, desto höher die Ausfallwahrscheinlichkeit. Insofern ist mir die autarke Türöffnung lieber, und die "Komfortfunktionen" laufen nebenher ohne Einfluss auf die Kernfunktion.

[2ndsky]

Das stimmt schon. Wenn ein Stromausfall nicht korrekt erkannt wurde und der Rechner auf dem sh.py läuft deshalb vielleicht nicht wieder gestartet wurde, dann muss ich auch den Schlüssel verwenden. Da aber auch das Steuergerät ausfallen kann (oder wie es bei mir auch schon vor kam, dass das Motorschloss mal hakt), ist es immer sinnvoll irgendwo einen Schlüssel deponiert zu haben oder ihn zusätzlich noch bei sich zu tragen.

[tuxedo]

UweH
Wie ist der aktuelle Stand bei dir?
Hast du den Rest auch noch geknackt?
Bin noch gar nicht dazu gekommen weiter zu machen. Und ehrlich gesagt hast du mich mit deinen letzten Posts bzgl. des CRC etwas "abgehängt".

Da ich für zwei weitere RS485-Projekte (Helios Lüftung + Dimplex Heizung) bereits reine Software-Lösungen habe, wäre hier ein Software-Lösung für den eKey wohl optimal (da HW schon vorhanden und noch ausreichend Ressourcen frei und für dritte einfach nachzubauen). Wenn du Software (für den AVR?) hast, wäre der Source dazu ganz praktisch. Dann könnte ich versuchen den zu portieren damit er auf ARM/x86/AMD64 Hardware läuft...

Gruß
Alex