Smart Home

Editorial: Firma pleite, Produkt platt, die Zweite

Wie kann der Weiter­betrieb von mit dem Internet verbun­denen Geräten sicher­gestellt werden, wenn der Hersteller insol­vent geht?
AAA
Teilen (12)

An dieser Stelle richte ich meinen Dank an die vielen Leser, die mit ausführ­lichen und konstruk­tiven Forums­beiträgen auf meine sicher sehr weit­gehende Forde­rung aus dem letzten Edito­rial reagiert haben: Es wäre kein kleiner Eingriff in die Gewer­befrei­heit, wenn Hersteller künftig für alle Produkte, die auf einen externen Server ange­wiesen sind, den Betrieb eben­dieses Servers auf geeig­nete Weise versi­chern lassen müssten. Denn neben dem Abschluss der Versi­cherung müsste der Hersteller auch nötige Quell­codes und Konfi­gura­tions­anlei­tungen bei der Versi­cherung hinter­legen, damit diese im Versi­cherungs­fall den Server­betrieb über­nehmen kann. Die Verbrau­cher hätten so natür­lich die Gewiss­heit, dass ihre Produkte nicht schon wenige Tage nach dem Kauf unbrauchbar werden, die Hersteller aber eben auch erheb­lichen zusätz­lichen Aufwand.

Etliche Leser erwähnten weitere Geräte, die wegen Abschal­tung von herstel­lerei­genen Servern vorzeitig zu Elek­troschrott wurden. Zwei Beispiele aus dem Bereich Fern­sehen: Der Grundig Selexx PDR 5000 S DIG war einer der ersten digi­talen Video­rekorder. Er bezog aber das elek­troni­sche Fern­sehpro­gramm von einem proprie­tären Server, der dann plötz­lich abge­schaltet wurde. Danach konnte man seine alten Aufzeich­nungen noch abspielen, aber keine neuen mehr anfer­tigen. Ein ähnli­ches Problem bekamen dieses Jahr auch Enter­tain-Altkunden der Telekom: Durch den Wechsel zu Magenta TV wurde der alte Receiver wertlos - ein Teil der Kunden hatte diesen anfangs als Kauf- und nicht als Miet­gerät erworben. Und egal, ob Receiver-Kauf oder -Miete: Mit der Umstel­lung auf die neue Platt­form waren die alten Aufzeich­nungen alle futsch.

Möglichst auf IoT-Server verzichten

Wie können ans Internet angebundene Geräte weiter funktionieren, wenn der Hersteller pleite geht?Wie können ans Internet angebundene Geräte weiter funktionieren, wenn der Hersteller pleite geht? User a1x schreibt, dass die Inter­netpro­vider mit Schuld an dem Problem hätten, da die ganzen IoT-Geräte hinter dem Heim­router nicht aus dem Internet erreichbar seien. Würden die Provider feste IPv6-Adressen verteilen und ihre Router so konfi­gurieren, dass sie Verbin­dungs­aufbau­anfragen aus dem Internet an die IoT-Geräte durch­lassen, dann würden viele der Herstel­lerserver über­flüssig. Um nicht gene­rell allen Traffic für alle Geräte frei­zugeben, was viele Sicher­heits­lücken mit sich bringen würde, würde es nach User a1x dabei reichen, wenn es eine Stan­dard­methode gäbe, mit der die Geräte einzelne Ports im Router für Internet-Traffic frei­schalten könnten.

Ich pflichte a1x bei, dass so mancher externer Server über­flüssig werden würde, wenn Smart-Home-Geräte verstärkt selber als Server agieren würden. Aber es gibt auch Gründe, die dagegen spre­chen: Viele IoT-Geräte haben nur eine lang­same CPU und sie müssen auch mit wenig RAM und ROM auskommen. Da passiert es schnell, dass die zusätz­liche Einbin­dung eines embedded Servers den Hersteller zwingt, den nächst­größeren und damit natür­lich auch nächst­teureren Chip zu verbauen. Auch die Gefahr von Prozess­abstürzen, die dann die Nutzer jeweils zum Reboot des Geräts nötigen, ist bei Servern höher als bei Clients. Sind Smart-Home-Geräte fest verbaut, wird dazu der Anwender in vielen Fällen die Siche­rung kurz ausschalten und dann wieder einschalten müssen. Es macht keinen Spaß, das zu tun, nur, weil ein "Script Kiddie" mal wieder Klin­gelstreiche spielt, also DDoS-Atta­cken gegen die bekannten Ports von smarten Türklin­geln fährt.

Vor allem aber ist jeder offene Port auch eine poten­zielle Sicher­heits­lücke. Wenn wir massen­haft IoT-Geräten erlauben, passiv auf Verbin­dungen aus dem Internet zu lauschen, dann müssen wir sicher­stellen, dass diese Geräte regel­mäßig mit Updates versorgt werden, und das insbe­sondere auch und gerade dann, wenn sie bereits kompro­mittiert sind. Man müsste also den IoT-Geräten ein beson­ders gehär­tetes "inneres System" spen­dieren, das zum Beispiel nach dem Booten aus einem gesi­cherten ROM über­nimmt, zunächst auf Updates prüft (wofür man wahr­schein­lich dann doch wieder einen externen Server braucht) und erst dann die eigent­liche Anwen­dung startet. Was passiert dann eigent­lich, wenn gerade jemand auf die smarte Türklingel drückt, während die im Update-Prozess steckt?

Schnitt­stellen veröf­fent­lichen statt Server versi­chern

User Beklug­scheiden schreibt, dass die Kosten im Versi­cherungs­fall in der Regel ziem­lich hoch wären: "Da kann man locker pro KMU, welches pleite geht, mit einem Mitar­beiter kalku­lieren." Und dieser Mitar­beiter muss dann so lange beschäf­tigt werden, wie die garan­tierte Betriebs­zeit des Servers beträgt. Bei einem wenig erfolg­reichen Produkt - schließ­lich ist der Hersteller pleite gegangen - würde der ganze Aufwand dann für nur wenige Nutzer getrieben werden.

Beklug­scheiden schlägt statt­dessen vor, "eine offene passive Schnitt­stelle, mit der alle Funk­tiona­lität repli­ziert werden kann", zu spezi­fizieren. Diese Schnitt­stelle würde erst im Insol­venz­fall veröf­fent­licht werden. Nach der Veröf­fent­lichung könnten dann Dritt­anbieter oder ambi­tionierte Hobby­entwickler die entspre­chende Lösung bauen. Damit vermeidet Beklug­scheiden natür­lich das Problem, dass Server für unter Umständen nur wenige Nutzer weiter­betrieben werden.

Warum ich gene­rell eher gegen passive Schnitt­stellen bin, habe ich im vorhe­rigen Abschnitt bereits erläu­tert. Die von Beklug­scheiden vorge­schla­gene Umstel­lung der IoT-Geräte von aktiver (Client-) auf passive (Server-)Betriebsart im Fall der Insol­venz des Herstel­lers beinhaltet aber noch weitere Probleme: Denn die Hersteller müssen bei dieser Lösung eine Schnitt­stelle imple­mentieren, die im Regel­betrieb gar nicht verwendet wird, da sie ja erst bei Ausfall des Hersteller-Servers zum Tragen kommen soll. Entspre­chend hoch ist die Gefahr, dass diese zusätz­liche Schnitt­stelle subop­timal getestet wird, und am Ende daher nicht oder nur unzu­reichend funk­tioniert.

Stich­haltig ist Beklug­schei­dens Argu­ment, dass die Versi­cherung einen hohen Aufwand mit dem Weiter­betrieb des Servers haben könnte. Nur: Versi­cherungen sind Spezia­listen darin, die Höhe eines mögli­chen Scha­dens und die Eintritts­wahr­schein­lich­keit desselben im Vorhinein zu kalku­lieren und ihre Kunden danach in Risi­koklassen einzu­teilen. Wer in einer Gegend mit hoher Einbruchs­rate wohnt, zahlt viel mehr für eine Haus­ratver­siche­rung als ein Bewohner einer beson­ders sicheren Gegend. Analog bei der Server-Weiter­betriebs-Versi­cherung: Wer seinen Code so orga­nisiert, dass auf dem Server nur eine Stan­dard-Daten­bank läuft, die als Service von Cloud-Anbie­tern bezogen werden kann, der zahlt bei der Versi­cherung entspre­chend viel weniger Beitrag als jemand, der 100 000 Zeilen proprie­tären Python-Code einreicht.

Durch die Risiko-Beur­teilung der Server-Versi­cherungen dürfte es daher zuneh­mend zur Stan­dardi­sierung der auf IoT-Geräte bezo­genen Cloud-Server kommen. In der Folge davon könnten die Kosten für die Hersteller sogar mittel­fristig sinken, weil eben nicht jeder Hersteller "das Rad neu erfinden" muss.

Vertrauen der Verbrau­cher verbes­sern

Einige Nutzer schreiben es direkt so, bei anderen meine ich, es zwischen den Zeilen heraus­lesen zu können: Weil sie schonmal erlebt haben, dass Produkte wegen Server-Abschal­tung plötz­lich unbrauchbar wurden, sind die User beim Kauf neuer Geräte eher zurück­haltend. Die genannte Versi­cherung würde somit zwar auf der einen Seite die Kosten für die Hersteller erhöhen, auf der anderen Seite aber das Vertrauen der Verbrau­cher stei­gern. Letz­teres stei­gert dann auch die Umsätze. Ich persön­lich gehe davon aus, dass die posi­tiven Effekte über­wiegen würden.

Teilen (12)

Weitere Edito­rials