www.mikrocontroller.net

Forum: Haus & Smart Home BidCoS-Funksignale sniffen, nur wie? (HomeMatic)


Autor: Marque (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe den Funk-Fenster-Drehgriffkontakt (ELV-Artikel-Nr.: 68-767-89) 
und den HomeMatic USB Konfigurations-Adapter (ELV-Artikel-Nr.: 
68-849-71) gekauft und den Sensor parametriert. So weit, so gut...
Mein Ziel ist nun die Daten, die der Sensor ausgibt, mit einem AVR 
einzulesen und auszuwerten. Da ich nur die Sensoren für eine 
Drehgriff-Stellungsanzeige verwenden will, habe ich die Verschlüsselung 
deaktiviert und den Übertragungsmodus auf Standard gestellt. Somit 
sollte der Sensor immer einen festen String senden?!

Auf Amber-Wireless habe ich folgendes gefunden:
http://amber-wireless.de/58-0-AMB8420.html
Könnte man damit die Funksignale "sniffen"?

Oder hat jemand soetwas ähnliches bereits umgesetzt?
Den USB-Port zu sniffen hab ich schon versucht, aber irgendwie scheinen 
die Daten nicht die Funkdaten zu sein, sondern Statusmeldungen vom 
Adapter.
Ich kann mich aber auch täuschen.

MfG,
Marque

Autor: Hardy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Marque,

die Funksignale von HomeMatic sind soweit mir bekannt ist verschlüsselt, 
da kanst Du nichts machen.

Hardy

Autor: Robert L. (lrlr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
aber (angeblich) eher schlecht verschlüsselt...

http://web.mac.com/tostmann/iWeb/Web-Site/Home/943...

Autor: Marque (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo ihr beiden.

Hardy schrieb:
> die Funksignale von HomeMatic sind soweit mir bekannt ist verschlüsselt,
> da kanst Du nichts machen.

Robert L. schrieb:
> aber (angeblich) eher schlecht verschlüsselt...
>
> http://web.mac.com/tostmann/iWeb/Web-Site/Home/943...

Schade schade schade...

Mir ist in der Nacht etwas anderes eingefallen.
Ich habe den USB Konfigurations-Adapter, mit dem man die 
HomeMatic-Komponenten parametrieren kann. Wenn ich meinen 
Funk-Fenster-Drehgriffkontakt schalten lasse, sendet dieser etwas zum 
USB-Adapter, der das Signal quittiert. Sichtbar ist das an der grünen 
LED, die an der kleinen Drehgriffbox kurz aufleuchtet.
Leider habe ich heute auch keine Zeit weiter zu experimentieren, aber 
ich könnte doch die Daten via Kabelanzapfung am USB-Adapter sniffen, die 
das Funkmodul an den Mikrocontroller weitergibt?!
Da ich nur die Daten (Stellungsrückmeldung) brauche, könnte man eine Art 
Filter im Sniffer-Mikrocontroller programmieren. Um die restliche 
Verbindung kümmert sich ja der USB-Adapter. So brauche ich mich nicht um 
die "sichere" Verbindung zu kümmern.

Anbei sind zwei Fotos, einige Pins vom ATMEL sind herausgeführt.
Weiß jemand, ob die Pins benitzbar sind?
Der ATMEGA ist ein ARM AT91S. Falls ich mich nicht verguckt habe, steh 
dann da noch folgend drauf: SM7 S128
Beim Funkmodul sind auch drei Pins herausgeführt (Steckkontakte), 
vielleicht ließe sich da was machen?!

Da ich nur einen Sensor habe, werde ich mir wohl einen zweiten besorgen 
müssen, um die Nutzdaten erstmal manuell via PC herausfiltern zu können.

Gruß,
Marque

Autor: Robert L. (lrlr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Sichtbar ist das an der grünen
>LED, die an der kleinen Drehgriffbox kurz aufleuchtet.

und der adapter ?

sicher dass der das quttiert?

(ich weiß jetzt nicht, wie das system genau funktioniert, vorallem ohne 
zentrale..)

aber am einfachsten wäre vermutlich ein funkempfänger (z.b. 68-767-99) 
den der drehgiffsender dann direkt (wenn das geht) schaltet..

Autor: Marque (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Einen Schaltempfänger kann der Drehgriff ohne Zentrale schalten, das 
muss aber mit dem USB-Adapter parametriert werden..
Ich bin mir recht sicher, dass der USB-Adapter den Befehl quittiert, 
weil dessen Status-LED kurz flackert.
Der Adapter speichert intern die Teilnehmer. Trenne ich den Adapter vom 
5V-Netz, bekommt der Sensor keine Antwort mehr.

Autor: Robert L. (lrlr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
du könntest hier fragen:

http://www.ip-symcon.de
(im forum)

die haben u.U.  mehr erfahrung...

Autor: Marque (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Robert L. schrieb:
> du könntest hier fragen:
>
> http://www.ip-symcon.de
> (im forum)
>
> die haben u.U.  mehr erfahrung...

Okay, hier kann man weiterlesen:
http://www.ip-symcon.de/forum/f19/bidcos-funksigna...

Aber ich werde noch hier weiterlesen und ggf. Neues posten.
Wer sich nicht bei ip-symcon anmelden möchte, kann auch gerne hier 
antworten!
Danke!

Autor: PeterL (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Link zu IP-Something geht nicht mehr ... ist wohl offtopic. Scheint 
die verdienen auch ordentlich mit ...

Autor: Robert L. (lrlr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
schaut so aus..

wenn man so ein system als z.B. alarmanlage verkaufen will (oder daran 
profitiert), sind postings in denen es darum geht wie "sicher" das 
protokoll ist, wohl nicht sehr beliebt..

Autor: Sniffi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Die Homematic Komponenten verwenden alle den CC1100 von TI.

Einstellung:
RF-Registereinstellungen für den CC1100
Einstellungen im SmartRF® Studio
X-tal frequency: 26.000000 MHz
RF output power: +10dBm, kein PA ramping
Deviation: 19.042969 kHz
Datarate: 9.992599 kBaud
Modulation: 2-FSK, kein Manchester-Codec
RF frequency: 868.299866 MHz
Channel: 199.951172 kHz, Channel Number: 0
RX filterbandwidth: 101.562500 kHz


Die Funkdaten sind einfach nur ein wenig "XOR" verknüpft, um sie 
unleserlich zu machen. Verschlüsselung ist das nicht. Auch nicht die 
beworbene AES authentifizierte Kommunikation. AES wird meines Erachtens 
nur für ein Challenge-Response verfahren verwendet, um zu checken, ob 
ein sicherheitsrelevanter Sender zum System gehört (Systemschlüssel).

Um die Daten leserlich zu machen:

dec[0] = enc[0];
dec[1] = (~enc[1]) ^ 0x89;
for (l=2; l < n-3; l++) dec[l] = (enc[l-1] + 0xdc) ^ enc[l];
dec[l] = enc[l] ^ dec[2];

(ohne die beiden letzten Status-Bytes des CC1100 am Ende, enc[0] ist das 
Längenbyte)

Aufbau eines Frames:
byte 0: packet length
byte 1: message counter
byte 2: (unknown, possibly comm control byte)
byte 3: message type (e.g. 0x40)
byte 4+5+6 (4 = MSB): source device address (eg. 0x100383 )
byte 7+8+9 (7 = MSB): destination device address (eg. broadcast: 
0x000000)
byte 10... payload (channel, etc.)

Außerdem hier (http://www.homematic.com/index.php?id=151) die 
Firmware-Image herunterladen und entpacken. Das rootfs ganz normal 
mounten und mal reinschauen. Es gibt dort ein Verz., welches die XML 
Beschreibung aller Module enthält. Innerhalb einer XML-Datei steht dann, 
wie die Payload eines Frames aufgebaut ist.

Damit kann man dann schon Wetterdaten und Türkontakte auslesen. ;-)

Autor: klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Geht das in Richtung Benutzung OHNE die CCU ??

Autor: Fritz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Sniffi

Bist Du Dir da sicher? Ich habe mir den Konfigurations-Adapter LAN 
zugelegt und den Verkehr auf dem Netzwerk mit WireShark angeschaut.

Die Datenpakete sind bei gleichen Schaltvorgängen (Handsender EIN) immer 
gleich gross, jedoch sind die Dateninhalte jedes Mal unterschiedlich. 
Wenn man z.B. zwei Datenpakete vergleicht, dann ist kein Byte am selben 
Ort wie das andere.

Bei einer XOR Verknüpfung müssten zwei identische Schaltvorgänge die 
identischen Datenblöcke ergeben. Oder mache ich einen Denkfehler?

Autor: Guest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Fritz:

Die oben beschriebenen Datenpakete werden für die Funkkommunikation 
benutzt.

Der Datenverkehr per Netzwerk müsste eigentlich XML-RPC sein, wobei der 
Hersteller in die XML-Lib ein paar Erweiterungen für binäre 
Datenübertragung eingebaut hat. Das kann man sich aber auch in den 
Sourcen anschauen, wenn man diese herunterlädt.

Ich habe auch eine CCU zuhause, aber (noch) keinen Konf.-LAN-Adapter.
Ich kann die Konfigurationssoftware des LAN-Adapters aber trotzdem 
verwenden, in dem ich die Option "Entfernter BidCOS-Dienst" benutze und 
die IP der CCU angebe (Port war 2001/tcp glaube ich).

Auf der CCU läuft für jede Schnittstelle ein eigener Daemon, der per TCP 
angesprochen werden kann. Das Protokoll sollte XML-RPC sein. Der Daemon 
für die Funkschnittstelle (BidCOS) nennt sich "rfd".

Zum Thema XML-RPC siehe:
http://www.homematic-inside.de/software/windows/it...
http://www.homematic-inside.de/software/windows/it...

Fritz, könntest Du nicht mal ein paar Datenpakete von Wireshark posten?

Autor: Guest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn man "nur" über den LAN-Adapter alles mögliche abwickeln könnte, 
würde das ja schon reichen. In diesem Fall machte es auch keinen Sinn, 
die Funkschnittstelle weiter anzuschauen. Diese CCU loszuwerden wäre 
halt prima.

Autor: Icke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@fritz
Was bedeutet wohl "message counter"?

Autor: Julian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Mit der derzeitigen Head-Version von culfw:
http://www.koeniglich.de/culfw/culfw.html

kann man es decoded dumpen und auch senden:
culfw/tools/asksin-dumper.pl
Press Ctrl-D to stop.
01:19:39 nr: 8F cc: A4 ty: 40 s: 119123 d: 105123 pl: 03 2B .+
01:19:39 nr: 8F cc: 80 ty: 02 s: 105123 d: 119123 pl: 01 01 00 00 2E .....
01:19:54 nr: 90 cc: A4 ty: 40 s: 119123 d: 105123 pl: 02 59 .Y
01:19:54 nr: 90 cc: 80 ty: 02 s: 105123 d: 119123 pl: 01 01 C8 00 39 ....9

Autor: DocZoid (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

da ich kürzlich auch Homematic-Besitzer geworden bin und über kurz oder 
lang den Einsatz sicherheitsrelevanter Systeme (Keymativ, Winmatic) 
plane, interessiert mich die Sicherheit der AES-Authentifizierung.

zunächst mal zum Inhalt von web.mac.com...: der Artikel ist so 
reißerisch geschrieben dass ich mich echt schwer tue dem zu glauben.

"Und nochwas: AES mit vielen Aktoren über 868,3 MHz - wer hat das 
eigentlich zugelassen? (Nun endlich FM, oder immernoch AM moduliert?)"
-> BidCos ist FM-Moduliert. Und was soll das mit der Anzahl Aktoren über 
AES?

"Nachtrag: HomeMatic und BidCoS verwenden überhaupt keine wirkliche 
Verschlüsselung. Nicht einmal zu „Rolling Codes“ hat es gereicht. Daher 
ist ein Einsatz oder Umstieg erst recht nicht zu empfehlen - FS20 hat 
zwar das Gleiche Sicherheitsproblem ist aber mehr als die Hälfte 
billiger! "
->Die XOR-Verschlüsselung ist in der Tat ein Witz. Als ich es mir 
gekauft hatte bin ich allerdings auch davon ausgegangen, dass es gar 
keine Verschlüsselung gibt, sondern eben nur die zuschaltbare 
AES-Authentifizierung. Ist mir echt egal, ob mein Nachbar mitbekommt 
wenn ich das Licht schalte. Prinzipiell ist es mir auch egal wenn jemand 
mitbekommt dass ich die Tür aufschließe - so lange er die 
AES-Authentifizierung nicht besteht. Dann hat BidCos nicht wie im 
Artikel bemängelt das gleiche Sicherheitsproblem wie FS20...

Ich schätze nun, dass es sich bei der AES-Authenthifizierung um eine 
Challenge des Aktors und eine Response des Senders handelt. Enthält die 
Challenge auch einen Zeitstempel ("Verfallsdatum")? Wird bei einem 
Wechsel des Sicherheitsschlüssels der neue Sicherheitsschlüssel 
unverschlüsselt übertragen, oder mit dem alten Schlüssel verschlüsselt?

Vielleicht hat sich jemand ja schon damit beschäftigt?

Gruß
DocZoid

Autor: Guest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DocZoid schrieb:

> "Nachtrag: HomeMatic und BidCoS verwenden überhaupt keine wirkliche
> Verschlüsselung. Nicht einmal zu „Rolling Codes“ hat es gereicht. Daher
> ist ein Einsatz oder Umstieg erst recht nicht zu empfehlen - FS20 hat
> zwar das Gleiche Sicherheitsproblem ist aber mehr als die Hälfte
> billiger! "

Dieses Zitat kenne ich. Meiner Meinung nach war demjenigen aber nicht 
klar, was genau wie intern funktioniert.

> ->Die XOR-Verschlüsselung ist in der Tat ein Witz. Als ich es mir
> gekauft hatte bin ich allerdings auch davon ausgegangen, dass es gar
> keine Verschlüsselung gibt, sondern eben nur die zuschaltbare
> AES-Authentifizierung. Ist mir echt egal, ob mein Nachbar mitbekommt
> wenn ich das Licht schalte. Prinzipiell ist es mir auch egal wenn jemand
> mitbekommt dass ich die Tür aufschließe - so lange er die
> AES-Authentifizierung nicht besteht. Dann hat BidCos nicht wie im
> Artikel bemängelt das gleiche Sicherheitsproblem wie FS20...
>

Gibt es denn irgendwelche UseCases, wo man wirklich eine Verschlüsselung 
von Daten bräuchte? Eigentlich geht es doch bei den aktuellen Sendern 
und Aktoren nur um die Authentizität, oder?
Stichworte: Authentizität, Integrität und Datenschutz(Verschlüsselung)

> Ich schätze nun, dass es sich bei der AES-Authenthifizierung um eine
> Challenge des Aktors und eine Response des Senders handelt. Enthält die
> Challenge auch einen Zeitstempel ("Verfallsdatum")? Wird bei einem
> Wechsel des Sicherheitsschlüssels der neue Sicherheitsschlüssel
> unverschlüsselt übertragen, oder mit dem alten Schlüssel verschlüsselt?
>
> Vielleicht hat sich jemand ja schon damit beschäftigt?

Genauso ist es. Siehe hier die Beschreibung der AES Authentifikation.
http://www.homematic-inside.de/index.php/tecbase.h...
Ob es da auch einen Timeout gibt gibt, weiß ich nicht.

Das mit dem Wechsel des Schlüssels interessiert mich auch.

Übrigens: Hier gibt es Fortschritte, um ein Device Pairing zu 
simulieren.
http://cvs.berlios.de/cgi-bin/viewvc.cgi/fhem/fhem...

Autor: AES (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guest schrieb:
> Stichworte: Authentizität, Integrität und Datenschutz(Verschlüsselung)

Datenschutz: ist leider gleich null, da bei HM Komponenten jeder die 
Nachrichten mitlesen und interpretieren kann - es wird nichts 
verschlüsselt.

Authentizität: Durch AES Challenge-Response (CR) - allerdings scheint 
die Implementierung fehlerhaft. Nicht alle Kommandos erfordern eine 
positive CR. So gibt es Gerüchte wonach sich "gesicherte" Schalter zwar 
nicht einfach ohne AES CR 'on' / 'off' schalten lassen, 'togglen' kann 
man diese aber sehr wohl ohne AES CR.

Da das Protokoll nicht offen liegt darf man also gespannt sein was noch 
so über Zeit herauskommt. Gut für ELV, die haben dann Ihren Kram schon 
längst vertickt...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.