Ich mag EIB nicht besonders. Kann jeder Depp einbauen und bietet mir so weder Herausforderung meiner Kreativität und meiner Fähigkeiten, noch existiert hier die nötige Freiheit. Außerdem sind die fertigteile arg teuer.
am allerweichtigsten ist aber die Tatsache, dass der EIB absolut unsicher ist und keinerlei Manipulationsschutz und sicherheitsrelevante Aspekte abdeckt.
Ich persönlich favorisiere je nach Einsatzgebiet (einzeln oder eine Mischung aus) SPS mit propritären Bussen, RS485 (da bauteile sehr günstig), Servergestützte Systeme, dezentralisierte, über VPN mit Linux-basis verbundene Haupteinheiten und LON, evtl. auch LCN.
Traurigerweise bietet das alles immernoch keine umfangreiche Sicherheit bei den endsträngen zu Sensoren und Aktoren. Deshalb favorisiere ich folgenden Aufbau:
- Dezentralisierte Haupteinheiten, verbunden wie oben beschrieben.
- Bus-System für Ebene 2, z.B. LON.
- Die LON-I/O, AD/DA, Frequenzzähler, PWM-output-module und anderes auf Ebene 2 befindet sich in geschützten Bereichen, zu denen nur eine begrenzte Anzahl vertrauenswürdiger Personen zugang hat. Die Sensoren und Aktoren sind dann direkt mit diesen LON-Interfaces verbunden. So wird verhindert, dass jemand durch das eigenmächtige Einhängen einer Haupteinheit den Betrieb stört oder manipuliert.
- Der Einbau von Direkt an den Bus anzuschließenden Einheiten wie Touchpanel und ähnlichem ist kritisch. Besser finde ich Systeme, wo das Touchscreen-Display über Server angebunden ist. Der Server übernimmt die Benutzerverwaltung, das sog.
Accounting und die Aufzeichung aller Ereignisse, das
Auditing. Erst wenn sich der Benutzer einloggt und seine Daten verschlüsselt zum Server übertragen wurden, erhält er seine graphische Benutzeroberfläche mit seinem individuell anlegbaren Profil, ergänzt durch die Benutzerrechte, eingerichtet durch den Admin oder einen der Supervisor. Und erst nach diesem Vorgand werden die Steuerbefehle, die abgesendet werden, vom Server an das Bussystem weitergeleitet oder an einen Partnerserver geschickt, der sie seinerseits weiterleitet.
Die Benutzerauthetifizierung kann über login/Passwort, Transponder oder biometrische Systeme erfolgen. Für die normale Benutzung einfacher Raumfunktionen kann eine Oberfläche vom Admin freigegeben werden, die als Gastaccount das Schalten von Licht, die regelung der Raumheizung oder anderer, individuell vorgebbarer Funktionen ermöglicht.
Ich gebe allerdings offen zu, dass letzterer Punkt noch zu hoch für mich ist, da mein Kenntnisstand im Bezug auf die Ansteuerung und den Umgang mit Displays und Mikrocontrollern noch nicht ausreicht und ich erst richtig programmieren lernen müsste. Ein solches System würde mich aber sehr reizen.
Was ich ebenfalls für wünschenswert halte, ist ein entweder additiv oder alternativ (alternativ bis auf die Server-Ebene, die bleibt immer) ein Bussystem, dass von vornherein die komplette Kommunikation verschlüsselt. Das sollte so funktionieren:
Die einzelnen Komponenten sind z.B. über ethernet oder APPN+ (schon lange tot, aber ein Revival wär toll, da der Protokollstack brutalst zuverlässig und performant ist) verbunden und die Kommunikation läuft ähnlich wie beim VPN komplett verschlüsselt ab. Jede Sensor-/Aktor-Komponente
hat -
- eine Kennnummer/Buchstabencode zur schnellen Auffindung des Moduls bei der Konfiguration des Systems. vier Stellen kann der Admin an diese nummer selbstständig anhängen, falls mehrere gleiche Nummern in einem System vorkommen.
- eine nicht änderbare ID in Form eines privaten 1024-bit-Schlüssels, die weltweit einmalig ist, also nicht zweimal vorkommt
- eine nicht-änderbare 128bit-ID
- zwei vom master-controller zugewiesene 128-1024-bit-Schlüssel als zweite Geräte-ID
- Speicherplatz für zwei Mastercontroller-IDs (1024 bit)
- Speicherplatz für die drei öffentlichen Master-Schlüssel (1024-bit) des Master-Controllers
- Speicherplatz für die drei privaten signatur-Schlüssel des Master-Controllers
- Speicherplatz für 506 weitere private- oder öffentliche 128-1024-bit-schlüssel anderer Kontrolleinheiten.
- Speicherplatz für bis zu 16 VPN-Schlüssel
- 32MB Speicherplatz für sonstiges
- Eine Zuordnungstabelle der für diesen Sensor oder aktor zuständigen Kontrolleinheiten
- Einen 128MB-Speicher für Ereignisaufzeichnung
- Einen alternativen Netzwerkanschluss für redundante Systeme
- Überspannungsschutz
- eine mini-Stromversorgung für 24h Betrieb bei Netzausfall
- die Daten werden auch bei völligem stromausfall erhalten
- eine updatebare Firmware, die Daten bleiben dabei erhalten
- Programmierung, Backups und updates sind regional möglich über die subcontroller oder zentral über den mastercontroller.
- wlan-aufsatz anschließbar/anclipsbar
- GPS-sender anschließbar
- haben standardmäßig entweder signalgeber (piepser) oder mindestens eine signalleuchte
Die Kontrolleinheiten:
- Firmwareupdate möglich unter beibehaltung der Daten
- Haben ebenfalls einmalige IDs als 1024-bit-Schlüssel und 128-bit-Schlüssel und eine Kennzahl-/Zahlen-buchstaben-kombination
- Haben auch zwei zusätzliche Geräte-IDs als 1024-bit-schlüssel und einen dritten 128-bit-Schlüssel
- Speicherplatz für die zwei master-controller-IDs
- Speicherplatz für jeweils drei öffentliche- und signaturschlüssel der mastercontroller
- können ihn ihrem Bit-segment bis zu 1024 Bus-Geräte verwalten (sensoren/aktoren) bzw. 16384 ports
- Haben daher Eine Tabelle für die aufnahme von 8192 Bit pro Gerät für die Schlüssel/IDs und 128kB für Notizen (wo welches Gerät sich räumlich befindet, ... etc).
- Insgesamt sind 512 Controller in einem Verbund möglich
- Daher auch hier eine Zuordnungsliste für alles
- beide Zuordnungslisten werden vom mastercontroller verwaltet und sind verschlüsselt
- 256MB schneller Speicher für Benutzerprogramme
- erweiterbar durch SD-cards auf 4GB/8GB
- interner Speicher (highspeed-memory) aufrüstbar bis auf 4GB
- kompletter Überspannungsschutz
- enthalten kleines Netzteil
- haben selbst 48 I/O-ports, 12 AD/DA, 12 PWM-Outputs und 12 Frequenzzähler
- Bieten die möglichkeit, einen zweite subcontroller als slave anzuhängen, der den Betrieb bei störungen des subcontroller-master übernimmt
- integrierter GPS-Sender
- (irgendwas hab ich bestimmt vergessen)
Zuatznetzteile:
-Einfache stromlieferanten mit 1024- und 128-bit ID und kennnummer, zusätzlich Speicherplatz für 16 öffentliche oder signaturschlüssel
- können Statusmeldungen über Verbrauch und störungen oder drohender Überlast an die subcontroller oder den Mastercontroller seden
Master-Controller-Master:
- Firmwareupdate möglich unter beibehaltung der Daten
- haben keine festen IDs, diese werden vom Admin festgelegt.
- Verwaltet bis zu 1024 Subcontroller
- Anbindung an Server bezüglich Backup, Auditing und Netzwerkbridge
- Als Mastercontroller-master kann sowohl die master-Einheit, als auch ein Server mit Opensource-Software wie auch beides im Verbund (wenn eines ausfällt oder hängen bleibt kann das andere übernehmen) möglich. Durch die höhere Geschwindigkeit der Hardwarelösung sollte zumindest eine Hardwareeinheit vorhanden sein
- Alternativ dazu könnte es eine steckkarte für einen Server geben, die das schnelle memory und andere sachen enthält.
- kann mit Slaves oder Servern zu einem Cluster zusammengeschlossen werden
- Interner Speicher: 4GB, erweiterbar auf 8GB + 8GB SD + 1TB oder mehr durch Festplatten/NAS oder Firewire-Platten für ein Backup aller Subcontroller und Geräte ohne Server
- Umfangreiche zuordnungslisten: Enthält die IDs aller Subcontroller und hält die IDs aller sensoren/Aktoren für den Bedarfsfall vor
- WLAN-In-Jail-Bridge: komponenten können über Funktechnik eingebunden werden, dabei herrschen besondere Sicherheitsvorkehrungen gegen manipulation sowie neben der WPA2-Verschlüsselung die VPN-Tunnelung
- Router: Fungieren als Router oder Bridge, um den Bus mit einem Ethernet oder anderem Netzwerk zu koppeln
- Alternativ: Kopplung mit EIB/KNX, LON, LCN, RS485, ... etc)
- Gleiches Identifikationskonzept wie bei subcontrollern und sensoren/Aktoren
- 512MB integrierter Ereignisspeicher und 128MB Programmspeicher
andere Komponenten: Touchpanel,... etc.
Das Konzept: Zunächst wird der Mastercontroller-master angeschlossen, mit Schlüsseln bestückt etl. mit Slaves oder externgeräten verbunden und konfiguriert.
Nun werden die Subcontrollermaster an den ControlBus angeschlossen und initialisiert. Sie erhalten dabei vom Mastercontroller zugewiesene Schlüssel, die IDs der Subcontroller werden im Mastercontroller gespeichert, schlüssel werden erzeugt und abgegelichen ("Fingerprinting").
Aus den festen IDs von Subcontroller und Mastercontroller wird ein verschlüsselter Schlüssel erstellt, den öffentlichen erhält der Subcontroller, den Privaten der Mastercontroller. Nun ist der Subcontroller fest mit dem Master verbunden. So wird mit jedem vorgengangen, bis alle Subcontroller initialisiert sind. etwa auf die gleiche art geht man im Applicationnnet (Bus zwischen sensoren/aktoren/anderen geräten und den Subcontrollern) vor, bis auch dort alle module initialisiert sind, nur mit dem Unterschied, dass man nach der Initialisierung der Subcontroller bequem alles vom Adminplatz am mastercontroller machen kann und es zusätzlich scripte zur vereinfachung gibt.
Als nächstes wird das Anwendungsprogramm erstellt. indem festgelegt wird, wer wo wann was machen darf und wer nicht und was passiert, wenn user x an modul y taste Z drückt oder aktor x an modul y befehl z enthält. Außerdem natürlich die gewohnten Automationsabläufe und den ganzen klimbim.
Die programmdatei wird gehashed und mit dem niedergestellten öffentlichen Schlüssel des mastercontrollers verschlüsselt und der ein hashwert im mastercontroller deponiert. Bei jeder Schalthandlung, die zuvor ale sicherheitsrelevant festgelegt wird, wird der hash zur kontrolle an den mastercontroller gesendet. Aus sicherheitsgründen muss sich ohnehin jeder subcontroller stündlich beim master melden. Programmänderungen am subcontroller werden, sofern keine signatur des masters vorliegt, nicht angenommen.
Mehr zu dieser idee später mir fallen sonst die Finger ab
MfG; Fenta
