Parameter aus OpenKNX Gerät auslesen

[henfri]

Hallo,

so, hier steigt weißer Rauch auf (keine Sorge: ich habe nicht gelötet. Ist eine Metapher):

newPassword: FingerprintHinte[MARKIEREN]␦[/MARKIEREN] (crc: 831306104)

In der ETS hatte ich aber nur FingerprintHinte (ohne das Sonderzeichen, was auch gar nicht in die 16 Zeichen passt) eingegeben.

Der CRC32 831306104 ist aber der von

password_str = "FingerprintHinte␦"
password_bytes = password_str.encode("utf-8")[:16]  # nur die ersten 16 Bytes

crc = zlib.crc32(password_bytes) & 0xFFFFFFFF​

Der Microcontroller läuft also mit dem Passwort mit dem umgekehrten Fragezeichen, wohingegen die ETS mit dem Passwort ohne Sonderzeichen kommt.

Ich weiß nicht, woher das Sonderzeichen kommt.
Zwei Theorien.
1) ich habe das Passwort mit STRG+V eingefügt und die ETS hat da Mist gemacht
2) der Microcontroller liest ein byte zu weit und kommt in einen "random" Speicherbereich.


Ich würde das gerne weiter debuggen. Aber wie komme ich jetzt einfach aus diesem Zustand wieder raus?
Der Fingerprint hat jetzt ja ein Passwort, welches ich über die ETS nicht eingeben kann, da es ein Zeichen zu viel hat.
Ich kenne ja das Passwort (831306104). Ich könnte es manuell (serielles Interface) auf 0 setzen.
Es bleibt aber das falsche Passwort im Flash des scanners. Den kann ich durch Code-Änderung auch dazu bringen das zu leeren. Aber gibt es einen einfacheren Weg?

Mir ist nochwas aufgefallen:

0d 00:21:32: Fingerprint: Function property finger: Set password
0d 00:21:32: Fingerprint: passwordOption: 2
0d 00:21:32: Fingerprint: newPassword: FingerprintSchup (crc: 961173143)
0d 00:21:32: Fingerprint: oldPassword: (crc: 3971697493)
0d 00:21:32: Fingerprint: currentCrc: 831306104
0d 00:21:32: Fingerprint: Invalid old password provided.​

oldPassword: (crc: 3971697493)

Da sollte nicht nur das crc vom "oldPassword" (das ist das aus der ETS, nicht das vom Microcontroller) stehen, sondern auch das Klartext PW:

    if (passwordOption == 2)
    {
        char oldPassword[16] = {};
        for (uint8_t i = 0; i < 16; i++)
        {
            dataOffset++;
            memcpy(oldPassword + i, data + dataOffset, 1);
            if (oldPassword[i] == 0) // null termination
                break;
        }
        if (oldPassword[0] != 48 || // = "0": if user inputs only "0", we just use it as is without CRC
            oldPassword[1] != 0)    // null termination
            oldPasswordCrc = crc32.crc32((uint8_t *)oldPassword, 16);
        logDebugP("oldPassword: %s (crc: %u)", oldPassword, oldPasswordCrc);
    }​

Das oldPassword scheint aber leer zu sein.

mumpf, abtools Ich bin nicht sicher, was ich anders mache als ihr.... Aber ich hoffe, das hier hilft.

Gruß,
Hendrik

[zenvy]

Ich hab da aus Interesse mal draufgeschaut und der CRC für FingerprintHinte (ohne rückwärts ?) ist 831306104.
Das rückwärts ? kommt in der Ausgabe, weil der newPassword buffer zu kurz ist, der ist exakt 16 bytes, dein Passwort ist 16 bytes, der wird nie null-terminiert und dann wird mit %s natürlich solange ausgegeben bis eine 0 gefunden wird.

Aber ich glaube der Fehler ist, dass im JS immer eine \0 angehangen wird, auch wenn das PW 16 Zeichen hat. Damit hat es aber 17 bytes, die Schleife in C geht aber nur 16mal durch. Damit bekommt die zweite Schleifen mit dem um 16 inkrementierten dataOffset dann direkt ein \0.

[traxanos]

Generell ist das alles Quatsch. Warum der Umweg? Warum sendet man nicht einfach die Zahl. Dann passt das auch in ein Standardframe. Und dann macht man das encoding im JavaScript Oder besser noch man fragt einfach die Zahl als Passwort ab. Sehr umständlich und fehleranfällig umgesetzt.

[henfri]

Hallo,

zenvy Vielen Dank für deine Neugier und Analyse. Klingt überzeugend.
traxanos Ich würde es nicht Quatsch nennen. Und ich gehe davon aus, dass Waldemar und Andreas sich etwas dabei gedacht haben.

Ich verstehe das aktuelle Design aber auch nicht und hielte es für robuster die Zahl direkt aus der ETS an den Controller zu senden. Ich weiß auch nicht, warum hier eine CRC verwendet wird. Das macht das Problem im Fehlerfall nur größer, erzeugt aber keine zusätzliche Sicherheit.
Aber das ist müßig, denn es wird nicht leicht das zu ändern und gleichzeitig updatefähig zu bleiben.

Allerdings: Vor Allem folgendes ist kritisch:
Wenn man das Passwort ändern will, muss in der ETS das Alte eingegeben werden, auch wenn der Controller das Alte schon (viel besser ) kennt. Wenn es also - warum auch immer - zu einem nicht synchronen Zustand zwischen Controller und ETS kommt (z.B. wenn man einen älteren Zustand der ETS via Backup oder Restorepoint) wiederherstellt, kommt man in eine Falle - selbst wenn der o.g. Bug behoben ist.

Ich denke, eine Änderung des Designs auf folgendes wäre gut:
- Anzeige in der ETS ob der FP mit dem Controller aktuell kommuniziert --> PW ist richtig
- Passwort kann über ETS gesetzt (erstmalig), gelöscht und geändert werden - ohne Eingabe des Passwort. Denn das kennt der Controller ja schon.

Ich wüsste nicht, was da sicherheitstechnisch dagegen spricht.


Gruß,
Hendrik

[mumpf]

Ich hab mir gar nichts dabei gedacht, das hat Andreas implementiert... Allerdings hatte ich vorgeschlagen, nicht nur 4 Ziffern zu nehmen, sondern ein Wort und daraus ein Surrogat zu bilden.
Hendrik, ne Frage: Hast du bei dir für dein ETS-Projekt eine andere Codepage eingestellt als die Standard Page ISO8859-15? GVS will Z.B. für ihre Taster, dass man auf UTF8 umstellt.
Ist nur aus Interesse, bei dem gewählten Passwort sollte es keine Codepage Probleme geben.

Gruß, Waldemar

[henfri]

Hi Waldemar,

Ich weiß nicht, wo man die Codepage einstellen kann. Daher ist es unwahrscheinlich. Aber ich gucke gerne nach. Wo finde ich das?

Ist nur aus Interesse, bei dem gewählten Passwort sollte es keine Codepage Probleme geben.

Und davon abgesehen hat zenvy den Fehler ja auch schon gefunden.

Der Fehler ist ja auch echt fies: Er kann zum Defekt des FP führen, wenn man nicht weiß, wie man das Passwort wieder her bekommt (und das kann sicher auch mit Anleitung nicht jeder). Er ist bisher wohl nur noch nicht aufgefallen, weil kaum jemand sein Passwort ändert (und wenn, tritt er ja nur bei einem 16 Zeichen PW auf). Vielleicht wäre eine Warnung im Haupt-Thread diesbezüglich nicht verkehrt.

Ich würde aber überlegen, ob das Verfahren nicht grundsätzlich geändert werden sollte.
Oben habe ich dazu ja schon etwas geschrieben.

Gruß,
Hendrik

[henfri]

abtools ich zitiere aus dem anderen Thread.

Probiere ich bei Gelegenheit mal aus und begrenze die Zahl dann halt notfalls auf 15 Zeichen in der ETS im Eingabefeld - das reicht ja auch mehr als aus.

Ich denke, das ist nicht die beste Lösung. Zwar reichen 15 Zeichen, doch ist das aktuelle Design in meinen (und nicht nur) Augen nicht so robust.
Es wäre in meinen Augen besser, wenn:
- die Zahl aus dem Passwort in der ETS übertragen wird. Es werden stets genau 16 Zeichen übermittelt.
- die Zahl auch in der ETS gespeichert wird
- weitere Kommentare, s.o.

Gruß,
Hendrik

[traxanos]

Das zeigt man baut sowas nicht nur so mal nebenbei ein und den Salat hat man jetzt. Hätte man es lieber garnicht eingebaut.

Ich weiß auch nicht, warum hier eine CRC verwendet wird. Das macht das Problem im Fehlerfall nur größer, erzeugt aber keine zusätzliche Sicherheit.

Da kann ich nur 100% Zustimmen!

Passwort kann über ETS gesetzt (erstmalig), gelöscht und geändert werden - ohne Eingabe des Passwort. Denn das kennt der Controller ja schon.

Du darfst dich nicht auf das Passwort in der Firmware verlassen. Das Passwort könnte wegen einem FP tausch falsch sein. Das Passwort könnte sogar fehlen, weil der Controller gewechselt oder gelöscht wurde.

Wenn man das macht müsste viel mehr in die Umsetzung stecken. Auch so wie es aktuell ins UI gebaut wurde... nicht sehr gut meiner Meinung nacht.

Es müsste eine eigene Seite "FP-Wartung" ö.ä geben. Dann sollte man sich von dem Passwort verabschieden und eine Zahl int (32bit) abfragen.

Dann braucht es mehrere Funktionen

* Lese aktuelles Passwort aus Controller (geht nur wenn man sich vom CRC verabschiedet)
* Schreibe Passwort in Controller
* Schreibe Passwort im Reader
* Prüfe ob Controller und Reader gültig sind
* Lösche Passwort im Reader
* Lösche Passwort im Controller

Dazu müsste es ein vernüftiges Fehlerhandling geben. Einige Schritte lassen sich intransparent noch kombinieren wenn man die UI clever gestaltet.

Aber der ganze Aufwand für was... naja das Kind ist in den Brunnen gefallen.

[abtools]

Hallo zusammen,

für mich ist diese Passwortgeschichte lediglich eine "Pseudosicherheit":
Ich meine, dieses Passwort (bzw. der Hash davon) wird nur ein einziges mal beim Init zum Fingerprint unverschlüsselt(!) über UART übertragen.
Was soll das für eine Sicherheit bringen?

Ich hab's nur mit in die ETS aufgenommen, weil's halt von der Fingerprint-Hardware unterstützt wird.
Aber vermutlich wäre es besser gewesen diese Funktion gar nicht anzubieten...

In jedem Fall werde ich in dieses Thema selbst keine weitere Zeit investieren außer den Bug so einfach wie möglich zu fixen und das scheint ja sehr leicht über die Verkürzung des Textfeldes in der ETS auf 15 Zeichen möglich zu sein. Das erledige ich beim nächsten Update der Fingerprintanwendung.

Viele Grüße
Andreas

[henfri]

Hallo,

ich stimme zu, dass es eine Pseudo-Sicherheit ist. Letztlich kann ich den FP emulieren und jedes Passwort akzeptieren und eine Finger ID von 1-999 senden - Sesam öffne Dich.
Nach meiner Odysee würde ich das vermutlich in einer Stunde hinbekommen. Fenster einschlagen geht dennoch schneller ;-)
Das lässt sich nur verhindern wenn der KNX Teil seine Arbeit verweigert, wenn die Kommunikation zum Sensor unterbrochen wird und wenn der KNX-Teil vor Zugriff sicher ist.

Aber das hatten wir ja alles schonmal.

Das Problem haben jetzt alle, die ein 16 stelliges Passwort genutzt haben. Hier wäre es wichtig, das Passwort in zukünftigen Firmwares nie zu überschreiben, oder an andere Stellen im Speicher zu schreiben. Auch kann es sein - das überblicke ich nicht - dass der Bereich der für das Passwort im Flash reserviert ist um eins verlängert werden sollte. Wenn sonst in einer zukünftigen Version dort etwas gespeichert wird, wird ein Teil des PW (bei mir das umgedrehte ?) überschrieben.

Gruß,
Hendrik

[henfri]

Hallo,

abtools, mumpf wenn die 1.0 jetzt die Passwort-Länge auf 15 reduziert (oder auch, wenn es eine andere Lösung wird), dann haben dennoch alle, die heute schon ein 16 stelliges PW haben ein Problem.
Dies wäre zu retten (so habe ich es gemacht) mit einer Fix-Firmware, die eine Passwort-Änderung auch erlaubt, wenn das aktuelle PW nicht korrekt eingegeben wird.
Ich poste hier mal nicht, wie das geht, aber es ist trivial.

Danach kann der Nutzer das Passwort ändern und auf 1.0 upgraden.

Gruß,
Hendrik