Home Automation: Es fehlen die Standards, die Schnittstellen, das gemeinsame

Der nächste Hype, das Smart Home. Aber wenn die Wirtschaft weiterhin so ignorant nur 20140712_133034auf die eigenen Marktanteile und Standards setzt, wird auch dieser neue Anlauf wieder im sprichwörtlichen Sande verlaufen.
Im Moment arbeiten 4 konkurriende Systeme in verschiedenen Testphasen bei uns zu hause. Da wären Hue als Ansteuerung für die Beleuchtung, Netatmo als digitale Wetterstation mit Fernzugriff, Gigaset Elements für die Hausüberwachung und AVM Fritzbox mit ansteuerbaren Steckdosen. Und komplett autonom arbeiten noch 4 Webcams rund ums Haus für die Außenüberwachung.

Also vier verschiedene Systeme mit vier verschiedenen zugrunde liegenden Technologien. Am ehesten kann ich hier noch mit Gigaset Elements zumindest in naher Zukunft vieles Abdecken, da im Moment die neue Webcam auf dem Weg zu mir ist und für das neue Jahr noch schaltbare Steckdosen und Rauchmelder angekündigt wurden.61MDaOZdiUL._SL1500_

Aber generell gilt, es muss alles zusammenspielen. Und zwar auf der Ebene der Protokolle und der Apps. Mit Apps wie imperihome gibt es zwar erste Ansätze, verschiedene Systeme zu integrieren, aber so lange das nicht für alle gilt ist für mich das ganze uninteressant, zumal nicht überall alle Systeme und Erweiterungen verfügbar oder einsetzbar sind.

Dienste wie IFTTT ermöglichen mir zwar in begrenztem Maß eine Integration von z.B. Netatmo mit Hue um bei Dämmerung oder entsprechend schlechtem Wetter die Lampen zu aktivieren. Aber eine Plattform im Web ist für mich eine Krücke für einen zu hause stehenden Server.

Und die Webcams kann ich nur indirekt über deren Alarmmails integrieren. Nutze ich hier einen bestimmten Betreff, kann ich über IFTTT zum Beispiel das Anschalten bestimmter Lampen triggern. AVMs Schaltsteckdosen sind hier noch gar nicht integrierbar und insofern fliegen diese wohl bald wieder aus dem Test.

Man spürt hier bei den Herstellern klar, dass die Bindung und das Einsperren des Kunden in das eigene System viel mehr  als der Nutzen für den Anwender im Fokus steht. Und Entwicklungszeiten von Jahren für Erweiterungen sind nicht wirklich nachvollziehbar, wenn andere Hersteller bereits Lösungen am Markt haben.

Mein Testsetup. Das Basispaket, ergänzt um einen Fenstersensor.
Mein Testsetup. Das Basispaket, ergänzt um einen Fenstersensor.

Vermutlich wird auch dieser Smart Home Anlauf scheitern, nicht daran, dass die Technologien nicht ausgereift wären, aber sie sind zu sehr Insellösungen, die nur mit dem entsprechenden Fachwissen integriert werden können. Und auch große Player wie Apple oder Google werden das Dilemma nicht lösen, sondern vermutlich alles nur noch komplexer gestalten.

Für mich als technisch sehr versierten Menschen ist es kein Problem, hier die System über Tricks und Kniffe miteinander zu verheiraten. Aber das bedeutet wieder hohen Aufwand und ist nicht wirklich das, was ich mir von einfachen Hausautomatisierungslösungen erwarte. Bevor hier weiter in die Entwicklung neuer Komponenten investiert wird rate ich den Herstellern DRINGEND zu einem runden Tisch, um sich zumindest über einheitliche Schnittstellen und Protokolle klar zu werden. Sonst kann hier noch so viel auf den Markt geworfen werden, der Erfolg wird ausbleiben.

 

Javaforum Stuttgart 2011 #jfs2011 Live Blogging Vortrag 5

Vortrag 5:
Safety First, Android sicher programmieren!

@elektrojunge on stage

Es gibt Dinge zu beachten, die nur für mobile Endgeräte gelten.
Android ist strukturiert wie ein Orchester mit vielen „Spielern“, verschiedensten Komponenten, die erst zur Laufzeit miteinander verknüpft durch die „Intents“ die Messengerkomponenten. Wie kann ich nun diese Komponenten absichern, wenn Intents schief laufen.

Es gibt das grobgranulare Sicherheitsmodell basierend auf der Sicherheit des Linux Kernels, der die Prozesse isoliert.
Desktop hat Single UID
Android hat UID per Application
Applikationen, die mit dem gleichen Schlüssel signiert sind, können mit der gleichen UID laufen.
Die Kommunikation zwischen Apps läuft über eine Binder IPC

Weiterer Schutz->Sandboxing von Applikationen
Ich kann nur meine eigenen Ressourcen ansprechen.
Jede App läuft in einer eigenen Instanz der Dalvik VM.
Kommunikation über spezielle Interfaces.

Weiterer Sicherheitsmechanismus
Signieren von Applikationen
Verantwortlich für die Signatur ist der Entwickler
Zertifizierung durch Entwickler und in Verantwortung des Entwicklers
Vertrauen in Entwickler durch Erstellung guter Anwendungen

Daneben Feingranulares Sicherheitskonzept
Basiert auf Permissions
Permissions schränken die Möglichkeiten ein, was Prozesse tun können.
Benutzer erkennt das an den angegebenen Rechten, die die App bei der Installation fordert.

Es gibt:
System permissions Erlaubnis auf Systemdienste zuzugreifen (z.B) Kalender oder Adressbuch
Custom permissions
Permission groups
Permission trees

Definiert werden die Permissions im Android Manifest.
Informationen über Apps und laufende Prozesse kann über PackageManager oder ActivityManager
PackageManager -> Installierte Programme
ActivityManager -> Laufende Programme

Wo sind die Verantwortlichkeiten des Entwicklers?

Per Default kann eine App vom „Umfeld“ nichts sehen.

Component wird exportiert durch android:exported im Intentsfilter

Intents sind vergleichbar mit Messengerobjekten
Niemals sensitive Daten in einen Intent
Ebenso von Anfang an angeben, wer den Intent sehen können soll.
Intentfilter filtern keine schädlichen Intents!
Ein Angreifer kann die Priorität seiner Intentfilter erhöhen.
Bei Intentfiltern spezifische Aktionen und Kategorien angeben und Datenfilter

Activities

Benuten von Activity android:permissions = „de.otw.android.HARM_USER_DATA“

Die Permissions werden in startActivity() bzw. startActivityforResult() geprüft.

Services

Client-> Intent.setComponent() um den Service eindeutig zu identifizieren.

Achtung bei der Verwendung von Binder Interface.

Genehmigung für ServiceConnection im Package Manager prüfen, vor dem Austausch sensitiver Daten.

Server: Genehmigung mit erzwingen
Feingranularere Zugriffskontrolle durch Verwendung von Binder und Context Hilfsfunktionen

Broadcast Receiver

Receiver: Wiederum eine Genehmigung erzwingen

Sender: Immer darüber nachdenken, wer den Intent empfangen können soll. Also einfordern einer Permission und Definieren des Empfängers des Intents.

Don’t user sticky broadcasts for sensitive data!

ContentProvider

Achtung, beim Verwenden eines ContentProvider intern, android:exported=“false“ explizit setzen.
Lese und Schreibrechte trennen
android:readPermission
android;writePermission

TAg schränkt zur Compiletime uri Zugriffe ein.

Mitkönne erlaubte Pfade für uri Zugriffe angegeben werden.

Tips:
Jegliche empfangene Daten aus einem Intent prüfen
SQL Statement und Daten die es enthält klar trennen.

Selection fields final machen um Kontaminierung aus Zufall zu vermeiden

Selektionen komplett vermeiden, Content_uris verwenden.

File I/O

Files, DB und geteilte Preferenzen könne mit Berechtigung installiert werden

Bei Zugriffsberechtigungen auf Datenbanken immer an die Konsequenzen denken und immer den User fragen.
Daten auf SD Karte NIE unverschlüsselt ablegen.

IMMER DRAN DENKEN Nutzerdaten SICHER speichern.

So wenig Permissions wie möglich, anstelle einer Permission manchmal besser ein Dialog.