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
:
Hallo Marque, die Funksignale von HomeMatic sind soweit mir bekannt ist verschlüsselt, da kanst Du nichts machen. Hardy
aber (angeblich) eher schlecht verschlüsselt... http://web.mac.com/tostmann/iWeb/Web-Site/Home/9436DEE2-7038-11DC-BEB2-001124368D6A.html
Angehängte Dateien:
-
Vorderseite.JPG
68 KB -
Rueckseite.JPG
72 KB
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
>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..
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.
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-funksignale-beim-usb-konfigurations-adapter-sniffen-9133/#post75244 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!
Der Link zu IP-Something geht nicht mehr ... ist wohl offtopic. Scheint die verdienen auch ordentlich mit ...
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..
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. ;-)
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?
@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/item/windows/hcstool.html http://www.homematic-inside.de/software/windows/item/windows/hmbinrpc.html Fritz, könntest Du nicht mal ein paar Datenpakete von Wireshark posten?
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.
Hi! Mit der derzeitigen Head-Version von culfw: http://www.koeniglich.de/culfw/culfw.html kann man es decoded dumpen und auch senden:
1 | culfw/tools/asksin-dumper.pl |
2 | Press Ctrl-D to stop. |
3 | 01:19:39 nr: 8F cc: A4 ty: 40 s: 119123 d: 105123 pl: 03 2B .+ |
4 | 01:19:39 nr: 8F cc: 80 ty: 02 s: 105123 d: 119123 pl: 01 01 00 00 2E ..... |
5 | 01:19:54 nr: 90 cc: A4 ty: 40 s: 119123 d: 105123 pl: 02 59 .Y |
6 | 01:19:54 nr: 90 cc: 80 ty: 02 s: 105123 d: 119123 pl: 01 01 C8 00 39 ....9 |
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
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.html?view=item&item_id=91 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/FHEM/10_CUL_HM.pm?view=markup
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...
Beitrag #5567894 wurde von einem Moderator gelöscht.
Beitrag #5567895 wurde von einem Moderator gelöscht.
Beitrag #5570099 wurde von einem Moderator gelöscht.
Beitrag #5570100 wurde von einem Moderator gelöscht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.