Reifendrucksensoren senden ihre Messwerte unverschlüsselt und unsigniert über Funk an das Fahrzeug. Als wir das erfuhren, war unser Interesse geweckt und ein kleines Team widmete sich der weiteren Erforschung.
Unser Einstieg in das Thema war das Paper Security and Privacy Vulnerabilities of In-Car Wireless Networks: A Tire Pressure Monitoring System Case Study von Ishtiaq Rouf et. al. Das Protokoll von Reifendrucksensoren ist nicht standardisiert und jeder Hersteller erfindet das Rad von neuem. Das Paper und eine kurze Internetrecherche zeigte aber einige gemeinsame Eigenschaften:
- Die Sensoren werden durch die Radialbeschleunigung des Reifens oder ein Signal bei 125 kHz aktiviert, also zum Senden gebracht.
- Es gibt keinen Rückkanal vom Auto zum Sensor.
- Systeme für den europäischen Markt senden auf dem ISM-Band bei 433 MHz.
- Als Modulation kommt Amplitude Shift Keying (ASK) oder Frequency Shift Keying (FSK) zum Einsatz.
- Oft sind die Daten Manchester-codiert.
- Die übertragenen Daten bestehen üblicherweise aus: Sensor-ID, Druck, Temperatur, Prüfsumme
Nach dem wir selbst einen Sensor in der Hand hatten, konnten wir über die eingelaserte FCC-Zulassungsnummer genaueres erfahren, denn die Zulassungsdokumente werden von der FCC online gestellt.
- Trägerfrequenz: 433,92 MHz
- Modulation: ASK
- Manchestercodierung
- Im Regelbetrieb wird alle 30 Sekunden ein Burst gesendet. Jeder Burst besteht aus 6 Paketen.
Da wir jetzt wussten, wonach wir suchen müssen, haben wir eine Testfahrt unternommen. Ein FUNcube Dongle wurde zusammen mit einer Dipol-Antenne für das 70cm-Band verwendet. Als Mittenfrequenz haben wir 433,93 MHz genommen. Die dabei entstandene Aufnahme sieht in der logarithmischen Darstellung von Audacity folgendermaßen aus:
Man erkennt regelmäßig eine hohe Signalstärke besonders zwischen 9:00 und 14:00. Das sind die Sendebursts, die wir suchen. Nach einer rechnerischen Bandbegrenzung und Betragsbildung kann man die Signalstärke gut erkennen (lineare Darstellung):
Wenn man sich den Sendeburst genauer ansieht erkennt man, dass dort alle Sensoren hinter und übereinander senden. Allein durch das sechsfache Wiederholen des Frames wird erreicht das meistens mindestens ein Frame pro Reifen nicht gestört ist. Die Frames bestehen aus einer 2 Bit langen Startsequenz, danach folgt Manchester mit On Off Keying. Die Drehung des Reifens führt zu einer Modulation der Signalstärke.
Um den Bitstrom zu rekonstruieren haben wir ein Matched Filter benutzt und die Zeitschlitze an den Maxima des Filters synchronisiert. So war der Empfang sehr robust gegen Störungen. Die Frames sahen dann etwa so aus:
0000011001001100000010000110101010101110101010100110100011101101110
0000011000001110000010000110101001111010100011000010100101011101110
0000011001001010000010000110101000111011110010100110100100000011010
0000011000001110000010000110101101011010100011000100100110001100101
Wie die Daten kodiert sind wussten wir noch nicht. Nun galt es die einzelnen Frames mit einanander zu vergleichen. Zuerst haben wir versucht Bitpositionen zu finden, die als ID in Frage kommen, um die Frames nach Sensor zu gruppieren. Dann haben wir versucht die least significant bits von Druck und Temperatur zu finden. Wir wurden schnell in der Annahme bestätigt, dass das Protokoll byte-orientiert ist, also jede Variable Vielfache von 8 bit belegt.
Während wir selbst versuchten die Frames vollständig zu dekodieren sind wir auf das Paper Applying Tire Pressure Monitoring Devices for Traffic Management Purposes aufmerksam, in dem der uns vorliegende TPMS-Sensor als Sensor B bezeichnet wurde. In dem Paper wird das Protokoll nahezu vollständig beschrieben.
Der Aufbau des Telegramms ist:
- 2 Bit-Zeiten Dauersenden (nicht Manchester-kodiert)
- 3 Bit feste Trainingssequenz (Nullen)
- 1 Byte unbekannt
- 4 Byte Sensor-ID
- 1 Byte (Reifendruck / 25 Pa)
- 1 Byte (Temperatur / °C - 50)
- 1 Byte CRC-8-CCITT
Für WDR Servicezeit wurde ein Beitrag hierüber gedreht. Dieser Beitrag wurde 2014-10-29 das erste mal gesendet.