DE102019120331A1

DE102019120331A1 - Datenübertragung zu einem IOT-Gerät

Info

Publication number: DE102019120331A1
Application number: DE102019120331.7A
Authority: DE
Inventors: Stephan Eberle; Abdelghani El-Kacimi
Original assignee: Itemis France Sas
Current assignee: Itemis France Sas
Priority date: 2019-07-26
Filing date: 2019-07-26
Publication date: 2021-01-28
Also published as: WO2021018489A1

Abstract

Die Erfindung betrifft ein Verfahren zur Kommunikation zwischen einem Gerät und einem Server, ein System umfassend mindestens ein Gerät und mindestens einen Server sowie einen Server, ein Gerät zur Verwendung in dem Verfahren und/oder dem System sowie ein Computerprogrammprodukt.Zur Kommunikation zwischen einem Gerät, bspw. einem vernetzten Gerät im Kontext des Internets der Dinge und einem Server wird zwischen dem Gerät und dem Server eine verschlüsselte Verbindung vereinbart. Um trotz beschränkter Hardware-Ausstattung eine sichere Kommunikation zu ermöglichen, wird eine maximale Datenrate für die Verbindung festgelegt und der Server überträgt Daten an das Gerät mit einer Datenrate, die die festgelegte maximale Datenrate nicht übersteigt.

Description

Die Erfindung betrifft ein Verfahren zur Kommunikation zwischen einem Gerät und einem Server, ein System umfassend mindestens ein Gerät und mindestens einen Server sowie einen Server, ein Gerät zur Verwendung in dem Verfahren und/oder dem System sowie ein Computerprogrammprodukt.
Insbesondere bezieht sich die Erfindung auf Geräte, die in den Kontext des Internets der Dinge fallen. Darunter versteht man die Verbindung und Vernetzung von elektronischen Geräten mit drahtlosen oder drahtgebundenen Netzwerkschnittstellen über das Internet. Solche vernetzten Geräte können auf direktem Wege Informationen mit PCs, Tablets und Smartphones austauschen und teilen. Dies eröffnet ein weites Feld von neuartigen Anwendungen und Einrichtungen, mit denen sich Einflüsse aus der realen und virtuellen Welt erfassen und analysieren und dazu passende Verhaltensweisen verwirklichen lassen. Als Folge dessen sind Fernseher, Lautsprecher, Uhren, Kühlschränke, Wasserhähne und zahllose weitere Gegenstände aus dem alltäglichen und beruflichen Umfeld dabei, „intelligent“ zu werden [1], [2], und auf nahezu allen Ebenen einen enormen Wandel und Fortschritt unserer Lebensweise einzuleiten.
Regelmäßig handelt es sich bei vernetzten Geräten um Massenprodukte, die über eine sehr knappe Hardware-Ausstattung verfügen. Die kann bspw. die Auswahl des Microcontrollers betreffen, ebenso aber auch die Speicherausstattung.
Eine ungeschützte Kommunikation vernetzter Geräte mit einem Server kann zu erheblichen Sicherheitsproblemen führen. Daher sind gesicherte Kommunikationsverbindungen zu bevorzugen. Die Konsequenzen eines Einspielens einer Schadsoftware auf einem vernetzten Gerät können sehr schwerwiegend sein. Ein prominentes Beispiel hierfür ist die Malware „Mirai“, die am 21 Oktober 2016 in Umlauf gebracht wurde [5] und sich insbesondere über ungesicherte und damit höchst anfällige vernetzte Geräte, wie z.B.
DVD-Player, TV-Decoder oder Überwachungskameras, sehr schnell ausbreiten konnte. Dies hat zu einem massiven Ausfall großer Teile des Internets geführt, der über mehrere Stunden hinweg angedauert hat.
Allerdings erweisen sich herkömmliche Verfahren und Vorgehensweisen für gesicherte Kommunikation als problematisch im Umfeld vernetzter Geräte mit knapper Hardware-Ausstattung.
Aufgabe der Erfindung
Daher kann es als eine Aufgabe angesehen werden, ein Gerät, einen Server, ein System aus mindestens einem Gerät und einem Server, ein Verfahren zur Kommunikation zwischen einem Gerät und einem Server sowie ein Computerprogrammprodukt vorzuschlagen, mit dem trotz beschränkter Hardware-Ausstattung eine sichere Kommunikation ermöglicht wird.
Erfindung
Diese Aufgabe wird gelöst durch ein Verfahren nach Anspruch 1, ein System nach Anspruch 15, einen Server nach Anspruch 16, ein Gerät nach Anspruch 17 und ein Computerprogrammprodukt gemäß Anspruch 18. Abhängige Ansprüche beziehen sich auf vorteilhafte Ausführungsformen der Erfindung.
Technisch gesehen kann ein vernetztes Gerät bspw. bestehen aus einer Elektronikeinheit, die sich aus Sensoren, Aktoren, einer Netzwerkschnittstelle sowie einem (oder mehreren) Mikrocontroller(n) zusammensetzt und in einem Gehäuse verbaut ist. Auf dem (oder den) Mikrocontroller(n) wird üblicherweise eine Firmware ausgeführt, die alle übrigen Elemente einbindet und ansteuert, die eigentliche Gerätefunktion realisiert und die gewünschten Formen an Informationsaustausch und Interaktionen über das Internet ermöglicht. Das vernetzte Gerät kann dabei bevorzugt als „System-on-Chip“ (SoC) realisiert sein, auf dem sowohl ein Mikrocontroller als auch eine Netzwerkschnittstelle, bevorzugt WLAN-Schnittstelle integriert sind.
Bei vernetzten Geräten handelt es sich gemeinhin um Massenprodukte. Um wettbewerbsfähige und rentable Produkte zu erhalten, zielen die Hersteller darauf ab, einen Großteil der Funktionalität über die Firmware zu realisieren und die Kosten für die Gerätehardware möglichst niedrig zu halten. Dies hat unmittelbare Auswirkung auf die Auswahl des Mikrocontrollers, der nahezu immer ein sehr kostengünstiges Modell ist und mit vergleichsweise wenig leistungsfähigen Hardwareressourcen ausgestattet ist. Die daraus resultierenden Beschränkungen können die Rechenleistung betreffen, die Flashspeicher- oder RAM-Speichergröße oder auch eine Kombination dieser Aspekte.
Aufgrund der knappen Hardware-Ausstattung ergeben sich Grenzen der Fähigkeit des vernetzten Geräts bezüglich des maximalen Datendurchsatzes, der noch verarbeitet werden, d.h. bspw. vom Gerät empfangen, entschlüsselt und/oder gespeichert werden kann. Liegt der von einem Server an das Gerät gelieferte Datendurchsatz oberhalb des maximal vom Gerät verarbeitbaren Datendurchsatzes, kann es zu Datenverlust kommen. Während bei herkömmlichen, gut ausgestatteten Geräten mit Netzwerk-Schnittstelle, bspw. Server oder Personal-Computern, üblicherweise die erreichbare Verarbeitungsgeschwindigkeit empfangener Daten so hoch ist, dass über das Netzwerk mit üblichen Netzwerk-Datenraten übermittelte Daten ohne Weiteres verarbeitet werden können, liegt die maximal erreichbare Verarbeitungsgeschwindigkeit bei den hier betrachteten vernetzten Geräten mindestens zeitweise unterhalb der vom Server lieferbaren Datenrate.
Während die Hardwarekomponenten eines vernetzten Geräts für gewöhnlich über seine gesamte Lebensdauer hinweg unverändert beibehalten werden, kann die Firmware - die oft auch als innovativer Kern des vernetzten Geräts angesehen wird - in leichter Weise und fast jederzeit durch neuere und leistungsfähigere Versionen ersetzt werden. Diese Fähigkeit ist eine Schlüsselfunktion eines jeden vernetzten Geräts. Durch sie kann sichergestellt werden, dass dasselbe physische Gerät über viele Jahre in Betrieb bleiben und genutzt werden kann, und sich dennoch Verbesserungen, funktionale Erweiterungen sowie Neuerungen aus virtuellen Welt einbringen lassen.
Die Aktualisierung (Update) der Firmware von vernetzten Geräten kann im einfachsten Fall durch manuelle Intervention eines Technikers direkt am Gerät erfolgen. Angesichts des zeitlichen und finanziellen Aufwandes, den dies nach sich zieht, ist diese Vorgehensweise jedoch höchst unattraktiv und bestenfalls als Notlösung geeignet. Viel passender ist es, diese Aktualisierungen „Over-the-Air“ (OTA) durchzuführen, d.h. sie über die Internetverbindung zu beziehen, über die das vernetzte Gerät ohnehin verfügt (wobei der Begriff „Over-the-Air“ durchaus auch so zu verstehen ist, dass davon eine Datenübertragung vollständig oder mindestens zum Teil über kabelgebundene Netzwerkverbindungen umfasst ist). Auf diesem Wege können individuelle Eingriffe auf jedem einzelnen Gerät vermieden werden. Stattdessen können anstehende Aktualisierungen automatisiert und simultan auf beliebige Zahlen von Geräten ausgerollt werden.
Mit der vorliegenden Erfindung ist es bspw. möglich, eine sichere OTA-Update-Funktionalität für die Firmware eines vernetzten Geräts zu realisieren. Dies kann erreicht werden, indem Updates der auf einem Mikrocontroller des Geräts ausgeführten Firmware von einem Webserver bezogen werden. Für Verbindung mit diesem können bspw. eine auf dem Chip integrierte Netzwerk-Schnittstelle und ein Gerät zur Herstellung der Netzwerkverbindung mit dem Server zum Einsatz kommen, bevorzugt über das Internet, bspw. in Form eines Internetrouters. Der Webserver kann bspw. die neuen Versionen der Firmware in Form von herunterladbaren Binärdateien bereitstellen. Das Gerät kann sich bspw. als Client mit diesem Webserver verbinden und die passende neue Firmwareversion herunterlagen. Das Gerät kann die neue Firmwareversion in einen freien Bereich seines Flashspeichers programmieren. Nach erfolgreichem Abschluss dieser Schritte kann das Gerät durch einen Neustart von der aktuellen auf die neue Firmwareversion wechseln.
Um eine Kommunikationsverbindung zur Durchführung der Kommunikation, insbesondere von OTA-Updates der Firmware vernetzter Geräte zu ermöglichen, kann bspw. das Herunterladen von Daten, bspw. Updates, vom dem bereitstellenden Server erfolgen. Bspw. kann der Server ein Webserver sein und die Kommunikation gemäß dem HTTPS (HyperText Transfer Protocol Secure) [6] -Protokoll erfolgen. Dabei handelt es sich um eine Kombination des Protokolls HTTP (HyperText Transfer Protocol) [7], das die Grundlage des World Wide Web (WWW) [8] bildet, und einer Verschlüsselungsschicht der Gattung SSL/TLS (Secure Sockets Layer/Transport Layer Security) [9]. Beide werden aufbauend auf einer TCP/IP (Transmission Control Protocol/Internet Protocol) [10]-Verbindung betrieben, die ihrerseits über die WLAN-Netzwerke, lokale Netzwerke (LAN) und Weitverkehrsnetze (WAN) verläuft, die sich zwischen dem vernetzten Gerät und dem fraglichen Webserver befinden.
Für die Umsetzung einer sicheren Datenkommunikation, insbesondere OTA-Update-Funktionalität für die Firmware von vernetzten Geräten, ist eine Unterstützung der vorstehend diskutierten Kommunikationsprotokolle sowohl auf Seiten des vernetzten Geräts als auch auf Seiten des Webservers vorteilhaft. Das vernetzte Gerät sollte vorteilhaft darüber hinaus über eine geeignete Logik, insbesondere geeignete Hard- und Softwarekomponenten zur Steuerung und Durchführung des Aktualisierungsprozesses an sich verfügen.
Zur Verwirklichung solcher Vorhaben unter Berücksichtigung der zuvor genannten Anforderungen und Randbedingungen können insbesondere Funktionen und Software-Bibliotheken genutzt werden, die bspw. TCP/IP-Verbindungen über eine Netzwerk-Schnittstelle, Dienste zum Aufbau Nutzen sicherer Tunnel über bestehende TCP/IP-Verbindungen unter Verwendung des Verschlüsselungsprotokolls SSL/TLS, und Dienste zur Durchführung von Firmware-OTA-Updates umfassen können.
Auf Seiten des Severs können neben einer passenden Serverhardware (für gewöhnlich ein PC) bspw. folgende Softwarekomponenten bzw. -schichten genutzt werden: Betriebssystem samt Unterstützung für das Herstellen und Nutzen von TCP/IP-Verbindungen, eine Implementierung des Verschlüsselungsprotokolls SSL/TLS und ein HTTP-Server-Softwarepaket einschließlich einer Implementierung des HTTP-Protokolls.
Um die erwähnten Problematiken bzgl. der Größe und der Übertragungsrate der heruntergeladenen Firmware-Fragmente zu lösen, ist es vorteilhaft, eine erweiterte Implementierung des Verschlüsselungsprotokolls SSL/TLS zu verwenden. Hierfür wären die jeweiligen Originalimplementierungen auf den vernetzten Geräten und dem Webserver durch diese zu ersetzen.
Insbesondere hat es sich als vorteilhaft erwiesen, dass eine maximale Datenrate für die Verbindung festgelegt wird und der Server Daten an das Gerät mit einer Datenrate überträgt, die die festgelegte maximale Datenrate nicht übersteigt. Bevorzugt kann das Gerät beim Verbindungsaufbau dem Server eine maximale Datenrate vorgeben.
Das erfindungsgemäße Computerprogrammprodukt kann bevorzugt eine Server- und eine Client-Komponente umfassen, wobei die serverseitige Software-Komponente auf dem Server ausgeführt wird und die beschriebene Verhaltensweise dort implementiert, während die clientseitige Software-Komponente auf dem Gerät ausgeführt wird, um die beschriebene Verhaltensweise dort zu implementieren. Insbesondere kann es sich jeweils um spezielle Software-Bibliotheken handeln, mit denen die Kommunikation abgewickelt wird.
Mit der Erfindung kann sichergestellt werden, dass das Gerät auch mit beschränkter Hardware-Ausstattung die Daten in der Form, in der sie vom Server empfangen werden, ordnungsgemäß speichern, entschlüsseln und/oder verarbeiten kann.
In vielen Ausführungen wird die Übertragung in Fragmente aufgeteilt erfolgen, wobei die Fragmente eine maximale Fragmentgröße aufweisen. Hierfür hat es sich als vorteilhaft erwiesen, dass die maximale Fragmentgröße ebenfalls beim Verbindungsaufbau festgelegt, insbesondere von Seiten des Geräts vorgegeben wird. Für die Fragmentgröße kann so ein für das Gerät geeigneter Wert gewählt werden.
Innerhalb eines Systems mit mehreren Geräten können dabei - bspw. je nach Typ des Geräts, Hardware-Ausstattung, etc. - unterschiedliche Parameter verwendet werden bspw. für die maximale Fragmentgröße und/oder für die maximale Datenrate. So kann die Datenübertragung für jedes Gerät auf passende Weise eingestellt werden.
Ausführungsbeispiel
Nachfolgend wird beispielhaft eine Umsetzung eines Ausführungsbeispiels der Erfindung näher erläutert. In dem Ausführungsbeispiel ist eine sichere OTA-Update-Funktionalität für die Firmware eines vernetzten Wasserleckmelders realisiert.
Dabei kommt als Mikrocontroller der ESP8266 [3] des chinesischen Chipherstellers Espressif zum Einsatz. Dieser ist ein sehr kostengünstiges „System-on-Chip“ (SoC), auf dem sowohl ein 32-bit Mikrocontroller als auch eine WLAN-Schnittstelle integriert sind. Die OTA-Updates der auf diesem Mikrocontroller ausgeführten Firmware soll von einem Webserver bezogen werden, für die Verbindung mit diesem soll die auf dem Chip integrierte WLAN-Schnittstelle und ein handelsüblicher Internetrouter zum Einsatz kommen. Der Webserver stellt die neuen Versionen der Firmware in Form von herunterladbaren Binärdateien bereit. Das betreffende Gerät verbindet sich als Client mit diesem Webserver, lädt die passende neue Firmwareversion herunter und programmiert sie in einen freien Bereich seines Flashspeichers. Nach erfolgreichem Abschluss dieser Schritte wechselt das Gerät durch einen Neustart von der aktuellen auf die neue Firmwareversion.
Im Ausführungsbeispiel eines Geräts mit dem Mikrocontroller ESP866 sind folgende Beschränkungen bzgl. der Hardwareressourcen zu berücksichtigen [4]

Prozessor: 32 bit
Taktfrequenz: 80 MHz ...160 Mhz
Flashspeicher (SPI Flash): 512 KB ... 4 MB
Interner RAM-Speicher (IRAM): 32 KB, davon tatsächlich verfügbar für die Applikation: < 6 KB
Statischer RAM-Speicher (SRAM): 80 KB, davon tatsächlich verfügbar für die Applikation: < 45 KB

Im Falle von vernetzten Geräten, die wie im vorliegenden Projekt auf dem Mikrocontroller ESP8266 beruhen, kann zur Erleichterung der Anwendungsentwicklung auf ein umfangreiches Softwareentwicklungspaket namens ESP8266 NONOS SDK [11] zurückgegriffen werden. Dieses umfasst u.a. folgende Dienste:

• Flexibel verwendbare Dienste zum Herstellen und Nutzen von TCP/IP-Verbindungen über die Chip-eigene WLAN-Schnittstelle (basierend auf der Open-Source-Bibliothek IwIP [12])
• Flexibel verwendbare Dienste zum Aufbau und Nutzen sicherer Tunnel über bestehende TCP/IP-Verbindungen unter Verwendung des Verschlüsselungsprotokolls SSL/TLS (basierend auf der Open-Source-Bibliothek axTLS [13])
• Fest vordefinierte Dienste zur Durchführung von Firmware-OTA-Updates [14]

Technologien für den Webserver
Zur Realisierung eines Webservers, auf dem sich die Firmware-Aktualisierungen für vernetzte Geräte bereitstellen lassen, werden neben einer passenden Serverhardware (für gewöhnlich ein PC) folgende Softwareschichten genutzt:

• Ein Betriebssystem samt Unterstützung für das Herstellen und Nutzen von TCP/IP-Verbindungen - in den meisten Fällen Linux oder Microsoft® Windows®
• Eine Implementierung des Verschlüsselungsprotokolls SSL/TLS - die bekanntesten Kandidaten sind OpenSSL [15], LibreSSL [16] und GnuTLS [17] unter Linux sowie Schannel [18] unter Microsoft® Windows®
• Ein HTTP-Server-Softwarepaket einschließlich einer Implementierung des HTTP-Protokolls - zu den Marktführern gehören hierbei Apache HTTP Server [19] und Microsoft® Internet Information Services [20]

Die Verwendung des ESP8266 NONOS SDK in der vorliegenden Fassung hat sich zur Realisierung der sicheren OTA-Update-Funktionalität für die Firmware als ungeeignet erwiesen. Dienste zur Abwicklung dieser Art von Operation über sichere Kommunikationsverbindungen sind zwar in der API des Softwareentwicklungspakets im Prinzip vorgesehen, jedoch ist die zugehörige Implementierung nicht vorhanden [21]. Auch nach Ergänzung der fehlenden Funktionalität durch eine eigene Implementierung konnte die sichere OTA-Funktionalität nicht realisiert werden.
Nach einer Analyse der aufgetretenen Fehler und Funktionsstörungen konnten durch die Erfinder folgende wesentliche Fehlerursachen identifiziert werden:

- Größe der heruntergeladenen Firmware-Fragmente zu hoch

Im vorliegenden Projekt betrug die Größe der Binärdateien mit neuen Versionen der Firmware des Wasserleckdetektors ca. 350 KB. Natürlich kann diese Größe in anderen Projekten und je nach Art des vernetzten Gerätes stark unterschiedlich ausfallen. Dennoch kann so gut wie ausgeschlossen werden, dass sich die Größe einer Firmware, die sichere OTA-Updates zu unterstützen hat, auf signifikant weniger als 100 KB beläuft.
Die maximale Datengröße, die über eine mit dem Verschlüsselungsprotokoll SSL/TLS gesicherte Verbindung in einem Zug übertragen werden kann, beträgt hingegen lediglich 16 KB [9]. Es handelt sich dabei keineswegs um eine durch die Protokollimplementierungen bedingte Limitierung, sondern um einen Parameter, der vom zu Grunde liegenden Protokollstandard festgelegt wurde. Somit werden alle Dateien oder Datenblöcke, die diese maximale Größe überschreiten, im Zuge der Übertragung in eine Serie von Datenfragmenten zerlegt, deren Größe jeweils gleich oder kleiner als der genannte Schwellwert ist.
Die Erfinder haben erkannt, dass sich aus der vom SSL/TLS-Protokoll vorgegebenen maximalen Größe der in einem Zug übertragbaren Daten das Problem ergibt, dass diese in keiner Weise mit den stark beschränkten Hardwareressourcen der meisten vernetzten Geräte im Einklang steht. Im vorliegenden Fall etwa betrug die maximale Datengröße, die auf dem Mikrocontrollers ESP8266 in einem Zug empfangen werden konnte, auf Grund seiner beschränkten RAM-Speichergröße weniger als 4 KB. Ein für die Bereitstellung von Firmware-Aktualisierungen genutzter Webserver, der auf einer Standardimplementierung des Verschlüsselungsprotokolls SSL/TLS beruht, hat jedoch keinerlei Möglichkeiten, solche Restriktionen in Erfahrung zu bringen und zu berücksichtigen. Daher zerlegt er jede zu übermittelnde neue Firmwareversion systematisch in eine Sequenz von 16 kB-Fragmenten. Als Folge dessen findet der Herunterladeprozess bereits unmittelbar nach der Ankunft des ersten Datenfragments auf dem vernetzten Gerät ein jähes Ende, da dessen Größe die dort verfügbaren freien Speicherkapazitäten bei Weitem überschreitet.

- Übertragungsrate der heruntergeladenen Firmware-Fragmente zu hoch Abgesehen von der vorstehend beschriebenen Problematik haben die Erfinder als weiteres Problem erkannt, dass sichergestellt werden sollte, dass die Fragmente einer neuen Firmwareversion, die auf dem vernetzten Gerät eintreffen, in hinreichend kurzer Zeit entgegengenommen und verarbeitet werden. Andernfalls besteht das Risiko, das das vernetzte Gerät bei der Ankunft der nachfolgenden Firmware-Fragmente immer noch mit der Verarbeitung der vorangehenden befasst ist und dadurch das eine oder andere Firmware-Fragment in Teilen oder als Ganzes verloren geht. Die Verarbeitung, der jedes empfangene Firmware-Fragment unterzogen werden muss, besteht aus zwei Teilschritten: seiner Entschlüsselung sowie der Programmierung in den Flashspeicher des Mikrocontrollers.

Die damit verbundene Problematik ergibt sich aus dem Umstand, dass jede dieser Operationen eine gewisse Zeit in Anspruch nimmt, vor allem wenn sie auf einem vernetzten Gerät mit beschränkten Hardwareressourcen durchgeführt werden.
Im Falle des Mikrocontrollers ESP8266 haben sich letztere als ausreichend erwiesen, um Firmware-Fragmente, die mit einer Übertragungsrate zwischen 8 KB/s und 10 KB/s eintreffen, zuverlässig entgegenzunehmen und zu verarbeiten. Ein für die Bereitstellung von Firmware-Aktualisierungen genutzter Webserver, der auf einer Standardimplementierung des Verschlüsselungsprotokolls SSL/TLS beruht, hat jedoch auch hier kaum eine Möglichkeit, Einschränkungen dieser Art Genüge zu leisten. Stattdessen übermittelt er die Firmware-Fragmente mit der maximal möglichen Übertragungsrate, die sich aus seiner Rechenleistung und den Betriebsbedingungen der zu durchlaufenden physischen Netzwerke ergibt.
Die daraus resultierende Übertragungsrate liegt im Regelfall weit oberhalb der zuvor genannten 8 KB/s bis 10 KB/s-Grenze. Infolgedessen gelingt es dem vernetzten Gerät zwar gelegentlich, die ersten Firmware-Fragmente erwartungsgemäß zu empfangen und zu verarbeiten, jedoch gelangt es anschließend rasch in einen Sättigungszustand und bricht den Herunterladeprozess auf Grund des Empfangs von unvollständigen oder inkonsistenten Firmware-Fragmenten ab.
Als Ausgangsbasis für eine Lösung der erkannten Probleme wurde im Ausführungsbeispiel die Open-Source-Bibliothek axTLS [13] herangezogen, die auch als Grundlage für die vom ESP8266 NONOS SDK bereitgestellten Dienste zum Aufbauen und Nutzen sicherer SSL/TLS-Verbindungen dient.
Erweiterungsmechanismus des Verschlüsselungsprotokolls SSL/TLS
Zur Umsetzung der erforderlichen Zusatzfunktionen in der SSL/TLS-Implementierung haben die Erfinder auf einen Erweiterungsmechanismus namens „Hello Extensions“ zurückgegriffen [22], der vom SSL/TLS-Standard eigens vorgesehen wurde. Er bietet Clients (hier die vernetzten Geräte) die Möglichkeit, mit dem Server, zu dem sie eine sichere Verbindung eingehen möchten, (im vorliegenden Fall der Webserver) die Verwendung bestimmter funktionaler Erweiterungen auszuhandeln. Dabei handelt es sich um optionale Verhaltensmerkmale des SSL/TLS-Protokolls, die auf Anfrage des Clients beim Aufbau neuer sicherer Verbindungen zu einem Server aktiviert werden können. Der SSL/TLS-Standard umfasst eine Liste [23], in der die bestehenden Erweiterungen dieser Art benannt sind, sowie auch entsprechende Spezifikationen [24], durch die deren jeweiligen Ziele und Funktionsweisen definiert werden.
„Maximum Fragment Length“-Erweiterung
Das Problem der zu hoch bemessenen Größe der heruntergeladenen Firmware-Fragmente haben die Erfinder mittels einer im SSL/TLS-Standard bereits vorgesehenen Erweiterung namens „Maximum Fragment Length“ [25] gelöst. Sie ermöglicht es einem Client, den Server, zu dem er eine sichere Verbindung aufbaut, aufzufordern, dass letzterer bei der Bemessung der an ersteren zu übertragenden Datenfragmente eine kleinere maximale Größe verwendet, als die 16 KB, die hierfür normalerweise vorgesehen sind.
Auf den ersten Blick mag dies als eine perfekte Lösung für das beobachtete Problem erscheinen. Bei näherer Betrachtung stellt sich jedoch heraus, dass es sich bei dieser Erweiterung lediglich um einen empfohlenen, aber keineswegs zwingend umzusetzenden Teil des SSL/TLS-Standards handelt [26]. Als Konsequenz dessen wird diese Erweiterung Stand heute von nahezu keiner der existierenden SSL/TLS-Implementierungen unterstützt. Zwar gibt es einige wenige Ausnahmen, wie z.B. GnuTLS [17] oder axTLS [13], die eine vollständige bzw. partielle Unterstützung dafür bieten. Jedoch werden diese nur sehr selten genutzt und die bekanntesten HTTP-Server-Softwarepakete - hier insb. Apache HTTP Server [19] und Microsoft® Internet Information Services [20] - machen keinen Gebrauch davon.
Die gewählte Lösung des Problems bestand daher in der Vervollständigung der partiellen Unterstützung der „Maximum Fragment Length“ Erweiterung, die in der axTLS-Bibliothek vorgefunden wurde. Auf Seiten der vernetzten Geräte wurde die solchermaßen veränderte axTLS-Bibliothek verwendet, um die Originalversion zu ersetzen, die im ESP8266 NONOS SDK enthalten ist. Darüber hinaus wurde der Applikationscode erweitert, um dem Webserver die maximale Größe der Datenfragmente mitzuteilen, die beim Herunterladen neuer Firmwareversionen zu benutzt werden soll. Auf dem Webserver wurde die modifizierte axTLS-Bibliothek in eine einfache HTTP-Server-Softwareimplementierung integriert (die der axTLS-Bibliothek als Beispielcode beiliegt). Als Ergebnis entstand ein sicherer Webserver, der die Fähigkeit besitzt, die Größe der zu übermittelnden Datenfragmente in individueller Art und Weise an die Restriktionen der mit ihm verbundenen vernetzten Geräte anzupassen.
„Maximum Data Rate“-Erweiterung
Für Problem der zu hoch ausfallenden Übertragungsrate der heruntergeladenen Firmware-Fragmente gab es im SSL/TLS-Standard sowie in den bestehenden Implementationen keine Lösungsmöglichkeit. Insbesondere war kein Mechanismus zur Beschränkung der Datenrate vorgesehen.
Die Erfinder haben als eine neue Erweiterung des SSL/TLS-Standards die Vorgaben einer „Maximum Data Rate“ entworfen und umgesetzt. Sie erlaubt es einem Client, den Server, zu dem er eine sichere Verbindung aufbaut, aufzufordern, die Übertragungsrate, die letzterer zur Übermittlung der Datenfragmente an ersteren verwendet, auf einen vorgegebenen Wert in KB/s zu begrenzen und so zu verhindern, dass die Datenfragmente in zu schneller Abfolge beim Client eintreffen. Ungeachtet des Umstandes, dass es sich hierbei um ein neuartiges Verhaltensmerkmal handelt, beruht die Erweiterung, die dessen Aktivierung ermöglicht, auf demselben Erweiterungsmechanismus „Hello Extensions“ [22], der auch für alle bestehenden Erweiterungen genutzt wird. Ihr wurde lediglich eine eigene eindeutige Kennung zugeordnet, die aus einem der Bereiche mit freien noch nicht vergebenen Kennungen ausgewählt wurde [23].
Um eine Implementierung des Verschlüsselungsprotokoll SSL/TLS zu realisieren, die diese neue Erweiterung unterstützt, haben die Erfinder ein weiteres Mal Veränderungen an der axTLS-Bibliothek vorgenommen, die bereits zur Vervollständigung der Unterstützung der „Maximum Fragment Length“-Erweiterung modifiziert worden war. Auf Seiten der vernetzten Geräte wurde eine neue Funktion in die Bibliotheksschnittstelle integriert, die es dem Applikationscode ermöglicht, die maximale Datentransferrate anzugeben, die vom Webserver beim Herunterladen neuer Firmwareversionen zu benutzt werden soll. Diese Information wird von der modifizierten Version der axTLS-Bibliothek bei jedem neuerlichen Aufbau einer sicheren Verbindung gemäß den Regeln des vom SSL/TLS-Standard vorgesehenen Erweiterungsmechanismus und unter Verwendung der dafür entworfenen neuen Erweiterung vom Client zum Server übertragen.
Auf dem Webserver haben die Erfinder die Teilfunktionalität der axTLS-Bibliothek, die für die Erkennung und Auswertung der vom vernetzten Gerät übermittelten Erweiterungsanforderungen zuständig ist, um die Fähigkeit zur Extraktion der anzuwendenden maximalen Datentransferrate ergänzt. Darüber hinaus wurde die Teilfunktionalität modifiziert, die für das Versenden der Daten vom Server an den Client verantwortlich ist, um die Übertragungsrate der ausgehenden Datenfragmente in entsprechender Weise anzupassen. Anstatt die zu übermittelnden Datenfragmente direkt aufeinander folgen zu lassen, wird nach jedem dem Versenden jedes Datenfragments eine Zeitverzögerung eingehalten, deren Dauer auf dynamischem Wege ermittelt wird. Dadurch werden die Datenfragmente auf der Zeitachse verteilt und die mittlere Datentransferrate bleibt unterhalb des vom Client vorgegebenen Wertes.
Als Ergebnis entstand ein sicherer Webserver, der in der Lage ist, die Übertragungsrate der zu übermittelnden Datenfragmente auf individuelle Art und Weise an die Restriktionen der mit ihm verbundenen vernetzten Geräte anzupassen.
Mit der Umsetzung einer Implementierung des Verschlüsselungsprotokolls SSL/TLS, welche die beiden zuvor diskutierten Erweiterungen sowohl in den vernetzten Geräten als auch auf dem Webserver nutzbar macht, wurden die notwendigen Voraussetzungen geschaffen, um die geforderte sichere Firmware-OTA-Update-Funktionalität für den hier betrachteten Wasserleckdetektor erfolgreich verwirklichen zu können.
Im Rahmen von Tests konnte nachgewiesen werden, dass das Herunterladen von neuen Firmwareversionen sowie deren Entschlüsselung und Programmierung in den Flashspeicher des Mikrocontrollers reproduzierbar erfolgreich verlaufen, wenn die Größe der zu übertragenden Datenfragmente auf 1 KB und die Datentransferrate auf 10 KB/s begrenzt werden. Diese Werte beziehen sich natürlich auf den speziellen Fall des Mikrocontrollers ESP8266 und sein Softwareentwicklungspaket ESP8266 NONOS SDK, die im hier diskutierten Projekt verwendet wurden. Für vernetzte Geräte, die auf anderen Mikrocontrollern basieren, können andere Werte gelten, die von Fall zu Fall ermittelt werden müssen.
Die Besonderheit des gewählten Ansatzes zur Behebung der beobachteten Probleme besteht darin, dass die gefundene Lösung weder auf ein bestimmtes vernetztes Gerät, noch auf einen spezifischen Mikrocontroller noch auf den Anwendungsfall Firmware-OTA-Update beschränkt ist. Vorteilhaft war dabei die Nutzung des vom SSL/TLS-Standard definierten Erweiterungsmechanismus „Hello Extensions“. Dieser beruht auf dem Prinzip der Verhandlung zwischen Client und Server, um beim Aufbau jeder neuen sichern Verbindung zu entscheiden, ob und welche zusätzliche Verhaltensmerkmale zum Einsatz kommen und welche Betriebsparameter dabei benutzt werden sollen. Die Erweiterungen, die im Rahmen dieses Projekts umgesetzt wurden, erlauben es somit jedem vernetzten Gerät, den Server, mit dem es sich verbindet, dazu zu veranlassen, jeweils individuell angepasste Größen und Übertragungsraten bei der Übermittlung von Datenfragmenten zu benutzen, die im Einklang mit den Beschränkungen seiner Hardwareressourcen und der zu erfüllenden Aufgabe stehen. Demzufolge können dieselbe erweitere Implementierung des Verschlüsselungsprotokolls SSL/TLS und ebenso auch derselbe Webserver, der diese nutzt, eingesetzt werden, um einerseits unterschiedliche vernetzte Geräte mit verschiedenen Mikrocontrollern zu bedienen und andererseits eine Vielzahl von Anwendungsfällen abzudecken, die eine sichere Kommunikation zwischen einem vernetzten Gerät und einem Server erforderlich machen.
Mit dem so realisierten Verfahren und System sowie mit den modifizierten Geräten und dem hierfür vorgesehenen Server war es erstmals möglich, OTA-Updates der Firmware von vernetzen Geräten durchzuführen, bei denen einerseits die Hardwareressourcen - oder genauer gesagt die RAM-Speicherkapazitäten - stark begrenzt sind und andererseits neuere Firmwareversionen dennoch über mittels des Verschlüsselungsprotokolls SSL/TLS gesicherte Verbindungen heruntergeladen werden sollen.
Dabei hat sich im Rahmen dieses Projekts herausgestellt, dass sich mit der Begrenzung der Größe der Datenfragmente allein lediglich ein Teil der beobachteten Probleme lösen lässt. Zusätzlich muss nämlich auch berücksichtigt werden, dass auf dem Mikrocontroller des vernetzten Gerätes nicht genügend RAM-Speicher zur Verfügung steht, um die Gesamtheit der herunterzuladenden Daten zwischenspeichern zu können und dass die Verarbeitung der heruntergeladenen Datenfragmente in Bezug auf die Übertragungsrate, mit der sie beim vernetzten Gerät eintreffen, zu viel Zeit in Anspruch nimmt. Die hierfür geschaffene Lösung in Form der neuen „Maximum Data Rate“-Erweiterung ist kein Bestandteil des bestehenden SSL/TLS-Standards.
Zu beachten ist, dass die Erfindung von relativ allgemeiner Natur ist und abgesehen vom hier vorrangig betrachteten Internet der Dinge auch in vielen anderen Bereichen (z.B. Industrie 4.0) genutzt werden kann. Sie stellt letzten Endes eine Weiterentwicklung des Verschlüsselungsprotokolls SSL/TLS dar, die insbesondere dazu geeignet ist, um gesicherte Kommunikation auf vernetzten Geräten nutzbar zu machen, die mit extrem knapp bemessenen Hardwareressourcen ausgestattet sind. Durch diese wurde es möglich, die im erläuterten Ausführungsbeispiel geforderte sichere OTA-Update-Funktionalität für die Firmware eines Wasserleckdetektors, der auf dem ESP8266-Mikrocontroller basiert, erfolgreich umzusetzen.
Die Erfindung ist jedoch in keiner Weise auf diese spezielle Konfiguration beschränkt. Sie kann genauso gut auch für andere vernetzte Geräte, Mikrocontroller und Anwendungsfälle genutzt werden, bei denen sich dieselbe Art von Problemen stellt.
Bibliographie

[1] Connect Object - Le blog des objets connectes http://www.connect-object.com
[2] Le Magazine des Professionnels de l'Internet des Objets http://www.objetconnecte.com
[3] ESP8266 - Low-power, highly-integrated Wi-Fi solution https://espressif.com/en/products/hardware/esp8266ex/overview
[4] ESP8266EX Datasheet https://espressif.com/sites/default/files/documentation/oaesp8266ex_datasheet_en.pdf
[5] Hacked home devices caused massive Internet outage https://www.usatoday.com/story/tech/2016/10/21/cyber-attack-takes-down-east-coastnetflix-spotify-twitter/92507806
[6] HyperText Transfer Protocol Secure https://fr.wikipedia.org/wiki/HyperText_Transfer_Protocol_Secure
[7] Hypertext Transfer Protocol https://fr.wikipedia.org/wiki/Hypertext-Transfer-Protocol
[8] World Wide Web https://fr.wikipedia.org/wiki/World_Wide_Web
[9] Transport Layer Security https://fr.wikipedia.org/wiki/Transport_Layer_Security
[10] Suite des protocoles Internet https://fr.wikipedia.org/wiki/Suite_des_protocoles_Internet
[11] ESP8266 Non-OS SDK API Reference https://www.espressif.com/sites/default/files/documentation/2c-esp8266_non_os_sdk_api_reference_en.pdf
[12] IwIP - A Lightweight TCP/IP stack https://savannah.nongnu.org/projects/lwip
[13] axTLS Embedded SSL http://axtls.sourceforge.net
[14] ESP8266 FOTA Introduction http://www.espressif.com/sites/default/files/99c-esp8266_ota_upgrade_en-v1.6.pdf
[15] OpenSSL - Cryptography and SSL/TLS Toolkit https://www.openssl.org
[16] LibreSSL https://www.libressl.org
[17] The GnuTLS Transport Layer Security Library http://www.gnutls.org
[18] Secure Channel https://msdn.microsoft.com/en-us/library/windows/desktop/aa380123(v=vs.85).aspx
[19] Apache HTTP Server Project https://httpd.apache.org
[20] A flexible & easy-to-manage web server... https://www.iis.net
[21] Firmware Over The Air (FOTA) for ESP8266 SoC
[22] The Transport Layer Security (TLS) Protocol Version 1.2 - Hello Extensions https://tools.ietf.org/html/rfc5246#section-7.4.1.4
[23] Transport Layer Security (TLS) Extensions https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontypevalues.xhtml
[24] Transport Layer Security (TLS) Extensions: Extension Definitions http://www.iana.org/go/rfc6o66
[25] Maximum Fragment Length Negotiation https://tools.ietf.org/html/rfc6o66#section-4
[26] [TLS] Maximum Fragment Length negotiation https://www.ietf.org/mail-archive/web/tls/current/msg22058.html

Claims

Verfahren zur Kommunikation zwischen einem Gerät und einem Server, bei dem - zwischen dem Gerät und dem Server eine verschlüsselte Verbindung vereinbart wird, - wobei eine maximale Datenrate für die Verbindung festgelegt wird, - und wobei der Server Daten an das Gerät mit einer Datenrate überträgt, die die festgelegte maximale Datenrate nicht übersteigt.
Verfahren nach Anspruch 1, bei dem - die Verbindung nach dem TLS/SSL-Protokoll verschlüsselt wird.
Verfahren nach einem der vorangehenden Ansprüche, bei dem - die Datenübertragung nach dem HTTP-Protokoll erfolgt.
Verfahren nach einem der vorangehenden Ansprüche, bei dem - die vom Server übertragenen Daten ein auf dem Gerät ausführbares Programm sind.
Verfahren nach einem der vorangehenden Ansprüche, bei dem - die vom Server übertragenen Daten ein auf dem Gerät ausführbares Betriebsprogramm (Firmware) sind.
Verfahren nach einem der vorangehenden Ansprüche, bei dem - das Gerät beim Verbindungsaufbau dem Server eine maximale Datenrate vorgibt.
Verfahren nach einem der vorangehenden Ansprüche, bei dem - die maximale Datenrate weniger als 16kB pro Sekunde, bevorzugt weniger als 12 kB pro Sekunde beträgt.
Verfahren nach einem der vorangehenden Ansprüche, bei dem - das Gerät automatisch vom Server ein Update seines Betriebsprogramms abruft, - das Update vom Server an das Gerät unter Einhaltung der maximalen Datenrate übertragen wird, - und das Gerät nach zumindest teilweiser Übertragung des Updates sein Betriebsprogramm aktualisiert.
Verfahren nach einem der vorangehenden Ansprüche, bei dem - das Gerät einen Mikroprozessor oder Microcontroller aufweist.
Verfahren nach einem der vorangehenden Ansprüche, bei dem - das Gerät ein SoC ist.
Verfahren nach einem der vorangehenden Ansprüche, bei dem - das Gerät mindestens einen Sensor für eine physikalische Umgebungsgröße und/oder mindestens einen Aktor zur thermischen oder mechanischen Einwirkung aufweist.
Verfahren nach einem der vorangehenden Ansprüche, bei dem - das Gerät über eine drahtlose und/oder über eine kabelgebundene digitale Netzwerkschnittstelle verfügt.
Verfahren nach einem der vorangehenden Ansprüche, bei dem - die Übertragung aufgeteilt in Fragmente erfolgt, - wobei die Fragmente eine maximale Fragmentgröße aufweisen, - und wobei die maximale Fragmentgröße beim Verbindungsaufbau festgelegt wird.
Verfahren nach Anspruch 13, bei dem - die maximale Fragmentgröße weniger als 16 kB beträgt.
System, umfassend - mindestens ein Gerät - und mindestens einen Server - mindestens eine Netzwerkverbindung zwischen dem Gerät und dem Server - wobei das Gerät und der Server dazu ausgebildet sind, dass zwischen dem Gerät und dem Server eine verschlüsselte Verbindung vereinbart wird, wobei eine maximale Datenrate für die Verbindung festgelegt wird, - und wobei der Server dazu ausgebildet ist, Daten an das Gerät mit einer Datenrate zu übertragen, die die festgelegte maximale Datenrate nicht übersteigt.
Server zur Verwendung in einem Verfahren gemäß Anspruch 1 und/oder einem System gemäß Anspruch 15.
Gerät zur Verwendung in einem Verfahren gemäß Anspruch 1 und/oder einem System gemäß Anspruch 15.
Computerprogrammprodukt, das beim Ausführen mittels einer Datenverarbeitungseinrichtung ein Verfahren gemäß einem der Ansprüche 1-14 ausführt.