TreeBus-only devices: Authentication Failed

[challo2018]

Hab die AlarmSirene Tree direkt auf dem TreeBus getestet. Wird problemlos erkannt und meldet auch z.b. Sabotagekontakt. Allerdings kommt nach kurzer Zeit der Hinweis Authentication failed. Leider kann ich in Crossstudio nur Compilieren aber flashen funktioniert nicht, Daher kann ich den Debugger nicht verwenden eventuell weitere Infos zu liefern. Hat jemand von euch Tree Geräte mit Crypto getestet? Läuft es bei euch?

[sarnau]

Ja, die Alarm Sirene muß den Sabotage-Kontakt melden – sonst gibt es eine Störung.

[challo2018]

Also sollte so kein Auth-Fehler kommen? void LoxBusTreeAlarmSiren::send_tamper_status(void) { this->hardwareTamperStatusOk = 1; send_digital_value(0, this->hardwareTamperStatusOk); // 1 = tamper status ok, 0 = tamper status failure }

[sarnau]

Das ist korrekt.

[challo2018]

Hmm ich bekomme leider immer noch den Authentifizierungsfehler. Erst danach taucht die Meldung Sabotage erkannt auf. Ich denke, da es dann keine Kommunikation mehr gibt. Hab auch das Phyton Script zum kopieren der Schlüssel nochmal neu ausgeführt. Läuft ohne Fehler durch und schreibt die Datei neu.

[sarnau]

Guck ich mir an. Die Autorisierung ist die gleiche, wie bei allen Tree Geräten. Eventuell ist da schlicht ein Bug drin. Probiere eventuell mal ein LED Tree Gerät oder ein Tree Touch via Software aus.

[challo2018]

Werde ich morgen direkt mal testen

[challo2018]

Bekomme den Fehler auch bei Tree Touch. Muss nochmal mein Aufbau auf LoxLink umbauen und eine Extension testen.

[sarnau]

Ich habe momentan keinen Testaufbau. Falls jemand CAN-Bus Logging Daten hat, kann ich es mir zeitnah ansehen.

[challo2018]

Einfach Traffic auf dem Tree Bus loggen während dem das Gerät angeschlossen und hinzugefügt wird und dann der Fehler kommt? Das kann ich versuchen...

[sarnau]

Das würde helfen.

[challo2018]

Kann die Daten morgen Abend aufzeichnen

[sarnau]

Ok, ich habe den Python Script LoxoneLink.py mal ein Weilchen laufen lassen. Dort klappt die Authorisierung und es gibt keine Fehler. Da ist somit zumindest schon mal ein Beispiel, wie es funktioniert. Das heißt das der STM32 Code wohl schlicht einen kleinen Bug hat.

[challo2018]

Hab den CAN Trace vom Tree Bus erstellt. Leider sind es einzelne Bilder da ich den Log irgendwie nicht exportieren konnte... Sorry. ist ein Zip mit den Bildern. In der Lox Config im Tree Monitor steht ständig folgendes: NAT request Nat offer Start Packet Config Data Packet

Das wiederholt sich dann relativ häufig. TreeBus_CAN_Trace.zip

[sarnau]

Lox Config stellt nur eine "Auswahl" an Messages dar. Ist sinnlos zum Gucken, was wirklich auf dem Bus los ist.

Die PNGs als Log sind natürlich extrem unleserlich, weil ich sie nicht mit einem Script bearbeiten kann und den Kram abzutippen – arg.

[challo2018]

Mach den Log nochmal neu. Mit einer anderen Software.

[challo2018]

Hier nochmal in einem anständigen Dateiformat: BUSMASTERLogFile_0.log

[sarnau]

Ok, das hilft. Ich kann inzwischen den Hex-Kram ganz gut direkt lesen, aber zum Berechnen der Verschlüsselung nehme ich doch einen Computer…

[sarnau]

BTW: Bei den Zeilen mit "0x117010F0 x 8 01 99" wird es interessant: Fragment_Start (0xF0) und CryptoDeviceIdRequest (0x99). Die Extension/das Device antwortet schlicht nicht. Das ist ein Problem…

[challo2018]

In loxconfig wird auch sobald der authentication Fehler kommt 100% Paketverlust angezeigt.

[chrisrock1984]

Genau dasselbe bei mir. Diagnose zeigt 100% Paketverlust

[sarnau]

Ok, ich habe in main.cpp folgende Zeilen aktiviert (plus die #include)

static LoxBusTreeExtension gTreeExtension(gLoxCANDriver, serial_base, gResetReason); static LoxBusTreeAlarmSiren gLoxBusTreeAlarmSiren(gTreeExtension.Driver(eTreeBranch_leftBranch), 0xb010035c, gResetReason); gTreeExtension.AddDevice(&gLoxBusTreeAlarmSiren, eTreeBranch_leftBranch);

und seit 1/2 Stunde die Tree Extension + Alarm Sirene an einem Miniserver 1 am laufen. Keine Authorisierungsprobleme. Ich habe zudem an dem Server eine "echte" Tree Extension plus Motion Sensor am laufen.

Sprich: ich kann das Problem nicht reproduzieren.

[challo2018]

Ich hab das Board direkt am tree Bus hinter einer realen tree Extension hängen. Dann könnte man auch Geräte emulieren und verwenden die nicht im Schaltschrank sitzen. Da lox Link bei den meisten ja nur dort verfügbar ist...

static LoxCANDriver_STM32 gLoxCANDriver(tLoxCANDriverType_TreeBus);

static LoxBusTreeAlarmSiren gLoxBusTreeAlarmSiren(gLoxCANDriver, 0xb010035c, gResetReason);

[sarnau]

Das habe ich nie getestet. Es wäre eventuell sinnvoll erst einmal nur Loxone Link zu testen, als auch noch gleichzeitig den Tree Bus.

[challo2018]

Eine Extension auf dem loxlink hatte ich auch schon laufen. Da gibt's bei mir auch kein Authentifizierung Fehler

[sarnau]

Ahh, ja, scheint so, daß die Challenge by Tree-Geräten nicht geht, aber bei LoxLink geht. Das müßte man doch mit a/b Vergleichen rausbekommen…

[sarnau]

Ich kann das momentan nicht vernünftig testen. Falls jemand es probieren will, was es zu finden gilt ist der Unterschied eines Tree Devices vs. einer Tree Extension + Tree Device mit diesem Projekt. Challenge/Response funktioniert ja bei dem Kombin-Setup, not als stand-alone Tree Device geht es nicht. Das muß sich ja finden lassen!

[challo2018]

Wie würdest du hier ansetzen? Ist der Fehler über ein Code Review zu finden oder gehst du davon aus dass es prinzipbedingt anders funktioniert wenn das Geräte direkt auf dem tree Bus läuft?

[sarnau]

Der Tree Bus is – zumindest von diesem Standpunkt – quasi transparent. Kommen Pakete im Tree-Device an? Dann geht zumindest schon mal CAN. Die wichtige Ausnahme von vor/hinter der Tree Extension: die Extension NAT und Device NAT im Paket. Diese Ausnahme kann das Problem sein, dies gilt es zu testen. Die Autorisierung selbst ist es nicht, die ist völlig transparent.

[sarnau]

Wichtiger Hinweis: der Miniserver merkt sich für jede Loxone Seriennummer bei Tree-Geräten die 12-Byte STM32-UID! Wenn die nicht paßt, klappt es nicht. Man kann problemlos den Cache im Miniserver löschen, indem man sich via FTP einloggt und /sys/device/settings.bin löscht und den Miniserver neu startet. Er macht dann – einmalig – pro Tree-Device einen Crypto-Device-ID request und erwartet eine Antwort mit der verschlüsselten Device-ID. Die wird für alle folgenden Challenge-Response genutzt!

[chrisrock1984]

Vielleicht bin ich der einzige, der das nicht versteht aber irgendwie ergibt sich für mich ein Henne-Ei Problem. Wie machen das originale Tree Geräte?

[sarnau]

Genau das gleiche: 12-Byte Device-ID wird beim ersten Mal angefordert (verschlüsselt mit einem globalen Key), dann wird die folgende Kommunikation inkl. des Challenge/Response mit diesem Key verschlüsselt. Es scheint, daß dies nur bei Tree Geräten der Fall ist. Ansonsten wird eine globale Device-ID genutzt – keine Ahnung warum, ich glaube weil die alte TI CPU keine Seriennummer hat.

[chrisrock1984]

Danke für die Erklärung. Eines noch - Wieso funktioniert es dann mit Tree Extension und emulierten Tree Device?

[sarnau]

Habe ich noch nicht angeguckt. Ich mußte erstmal ein Setup aufbauen – mir fehlte eine USB Schnittstelle

[chrisrock1984]

Ah, mein Fehler. Das waren ja die Python Scripts, die du laufen hast lassen ;)

[matlab22]

Ist in diesem Thema schon jemand weiter gekommen? Ich habe bei mir die DMX Extension getestet und auch diese meldet einen AuthFehler. Die DMX Extension hat einen LM3S2678 Prozessor. Könnte demnach schon an der Seriennummer liegen.

[sarnau]

Authorisierung sollte funktionieren. Hatte das vor einem Weilchen ja gefixt (für Tree Devices). Der Prozessor ist unwichtig.

[matlab22]

Bei der DI-Extension und der Relay-Extension funktioniert dies auch. Habe nun auf der gleichen Elektronik noch eine DMX am Laufen. Bei dieser kommt der Fehler jedoch.

[sarnau]

Ahh, sollte sehr ähnlich zur Relais Extension sein - nicht wie die NAT Geräte.

[challo2018]

Leider hab ich keine Ahnung wie ich das Thema mit tree Bus Geräten ohne simulierte tree Extension angehen soll... Vielleicht findet @sarnau die Zeit sich das an zu schauen

[KjellVerb]

@challo2018 , I am looking into the logging but still learning to decode the protocol. I do think that it would be great for debugging if you could provide CAN traces of the Loxone Link (between miniserver and extensions) for two cases: 1) Treebus-only LoxLink device 2) LoxLink Tree device behind LoxLink Tree Extension

[KjellVerb]

BTW: Bei den Zeilen mit "0x117010F0 x 8 01 99" wird es interessant: Fragment_Start (0xF0) und CryptoDeviceIdRequest (0x99). Die Extension/das Device antwortet schlicht nicht. Das ist ein Problem…

I see that the extension sends a CryptoDeviceIdReply(0x98) header, but it's followed by only 2 fragmented data packages instead of the expected 4 data packages for 32 bytes of data. I also see that the CryptoDeviceIdReply (E->S) packages are interleaved with SendConfig(0x11, S->E) packages.

I still need to learn how the code works precisely, but is it at all possible that receiving SendConfig during the Authorization stage causes interference and the Authorization state machine hangs? The LoxLinkTreeDevice only starts responding again after a watchdog timeout.

20200615_LoxCanDecode_Tree.xlsx

[KjellVerb]

It "only" took me two weeks but I finally found the solution to this issue.

The TreeDevice overrides the Master cryptDeviceID after it has received a CryptoDeviceIdRequest, but this process only happens the first time that the Miniserver discovers the TreeDevice. If the LoxLink-based TreeDevice gets reset, the cryptDeviceID variable gets reset to its default state. This means that the TreeDevice will encrypt the CryptoDeviceIdReply with the Master cryptDeviceID while the Miniserver expects that the UID will be used.

I'm not even sure whether this is a TreeBus-only issue...

The following addition to LoxNATExtension.cpp fixed it for me, I haven't been able to make it fail again.

  case CryptoChallengeRequest: // from the Miniserver: check the authorization of an extension
    if(this->driver.isTreeBusDriver()){
      HAL_GetUID((uint32_t *)this->cryptDeviceID);
    }
    memcpy(decryptData, data, sizeof(decryptData));
    ...

[challo2018]

Sorry for late Response ans No traces till now. Your solution Sounds great. Thanks a Lot for Analysis. I'll have a try and give Feedback

[challo2018]

I added the lines you mentioned but still getting the auth. Error. Do i have to Change sth. Else?

[KjellVerb]

Did you remove the settings.bin file and reboot the miniserver? I don't think that I changed anything else other than adding the one "if" statement.

I also noticed that printing debug statements with my st-link v2 slows down the microcontroller really badly, up to a point where it will behave unpredictably and have watchdog timeouts every once in a while. Maybe try to build in release mode and see whether that improves things.

[challo2018]

debugging is not working for me so it's release build and no debugger attached. Do i have to remove settings.bin even when i change the device serialnumber to a new one?

I now also tried to delete settings.bin and rebooted the miniserver. Auth Error occurs again. I attached my project. Maybe you can compare the files to yours?

Project.zip

[KjellVerb]

The settings.bin entry is not linked to the serial number but to the STM32 UID which is a unique code baked into the chip.

Maybe in the coming weeks I'll find the time to take a look, but currently I'm too busy with other stuff.

[challo2018]

I tried again with deleting settings.bin. But still getting the Error. Maybe you can upload your project here so i can compare it. Thanks a lot!

[KjellVerb]

The only difference I see is that I used a roomcomfortsensor tree instead of a tree touch, otherwise our projects are more or less identical.

[challo2018]

You are using tree Devices connected to an real tree Extension or you also simulate tree Extension?