IoT in der Industrie Sichere Kommunikation für das IoT

Dem heutigen Menschen erschließen sich dank verfügbarer Internet-Infrastruktur ständig weitere Anwendungsfelder. Auch die Industrie macht Gebrauch vom Internet und dessen Möglichkeiten. Allerdings muss das Thema Sicherheit direkt bei der Entwicklung dieser smarten Geräte berücksichtigt werden.

Die Sicherheit von IoT-Geräten hat vielfältige Ausprägungen. Für den Anwender der Geräte geht es um die Privatsphäre und den Schutz vor Manipulation. Aus Herstellersicht geht es darum, dass die Geräte bestimmungsgemäß verwendet werden, dass er Wartungsinformationen abrufen und Updates bereitstellen kann, und schließlich auch darum, dass die Geräte nicht kopiert oder geklont werden. 

Für einen Angriff gibt es eine Vielzahl an Wegen, die zum Ziel führen. Zunächst gibt es die direkte Manipulation, wenn physikalischer Zugriff auf das Gerät besteht. Hier greifen sogenannte Anti-Tamper-Maßnahmen-Schutz vor unberechtigten Zugriff. Eine weitere Achillesferse bildet die Kommunikation. In diesem Artikel geht es vor allem um den Schutz der Kommunikation und welche Rolle die Software dabei spielt.

Kommunikation ist verschiedenen Sicherheitsrisiken ausgesetzt. Die meisten Angreifer werden das System auf Schwachstellen abklopfen und dort ansetzen, wo der Angriff am vielversprechendsten mit Erfolg gekrönt werden könnte (Weakest Link). Dabei gibt es Angriffe, die die Kommunikation direkt angreifen, um Daten mitzulesen und zu manipulieren. Dazu kommen indirekte Attacken, bei denen nicht das Gerät selbst angegriffen wird, sondern Geräte, die mit dem eigentlichen Ziel kommunizieren. Sicherheitslücken, verursacht durch nachlässige Implementierungen, eröffnen dem Angreifer weitere Möglichkeiten (Dormant Bugs). Zuletzt bleibt noch der Faktor Mensch, der entweder unwissentlich oder schlimmstenfalls vorsätzlich Geheimnisse preisgibt. Ein Sicherheitskonzept mit Verschlüsselung ohne ausgereiftes Konzept für das Key-Handling leistet dem ganzen noch Vorschub.
 

Geschützte Kommunikation

Um Kommunikation schützen zu können, bedarf es zwei Grundvoraussetzungen. Die Kommunikation muss so gesichert sein, dass die gesendete Information nicht in lesbarer Form abgefangen werden kann und auch nicht manipulierbar ist.

Was bedeutet das in der Praxis? Zunächst muss sichergestellt werden, mit wem kommuniziert wird. Anschließend kann dann der verschlüsselte und damit gegen Abhören gesicherte Kanal aufgebaut werden. Mit wem kommuniziert wird, wird durch Authentifizierungsalgorithmen sichergestellt. Digitale Signaturen helfen, dass die Quelle von Nachrichten eindeutig identifiziert werden kann. Über Signaturen lassen sich zusätzlich Manipulationen und Übertragungsfehler an den Nachrichten erkennen. Passt die Signatur nicht zur Nachricht, wird diese abgewiesen und kann so auch nicht missbräuchlich eingesetzt werden. Voraussetzung dafür ist der gesicherte Austausch von Schlüsseln, der ähnliche Mechanismen anwendet. Nur so verdient Kommunikation zwischen zwei Teilnehmern das Prädikat „privat“. Das Verfahren, das sich zum Austausch der Schlüssel als auch das Absichern der Kommunikation selbst durchgesetzt hat nennt sich Secure-Socket-Layer (SSL) bzw. Transport-Layer-Security (TLS).

SSL/TLS verwendet sogenannte Zertifikate, um Schlüssel zu autorisieren und identifizieren. Beim Aufbau der Kommunikation wird wechselseitig abgestimmt, welche Algorithmen verwendet werden (Bild 1). Im Einzelnen ist der Ablauf wie folgt: Der Client – das kann eine Heizungssteuerung im Eigenheim sein – initiiert die Kommunikation mit einer »Hello« Message an den Host, nämlich den Server des Heizungsherstellers. Dieser antwortet mit seinem Zertifikat, und initiiert den Schlüsselaustausch. Zusätzlich legt der Server fest, mit welchen Verfahren die Schlüssel ausgetauscht werden, wie die Authentifizierung durchgeführt wird und mit welchem Verfahren verschlüsselt wird. Der Client bestätigt das Zertifikat und leistet seinen Beitrag zum Schlüsselaustausch. Üblicherweise tauschen Server und Client Zufallszahlen aus, deren Kombination die Basis für die Berechnung der Schlüssel bildet. Falls nötig, schickt der Client eine Anfrage auf einen Wechsel der Protokolle und Algorithmen. Danach beginnt die verschlüsselte Kommunikation.

Im Bereich TLS/SSL gibt es eine Vielzahl an Protokollen und Protokollkombinationen, die zum Einsatz kommen. Daher halten öffentliche Server auch nach Möglichkeit viele Protokolle vor. Clients müssen möglichst alle Protokolle unterstützen, um mit beliebigen Servern kommunizieren zu können. Welche Protokolle bevorzugt eingesetzt werden, hängt in der Regel von den Vorlieben des jeweiligen Herstellers oder Betreibers ab. Hieraus leitet sich allerdings für Mikrocontroller-basierte Embedded Systeme eine größere Herausforderung ab. Jedes unterstützte Protokoll benötigt Speicher für die zugehörigen Algorithmen.

Sicherheit mit wenig Speicher 

Bei der Planung des IoT-Gerätes und der verwendeten Sicherheitsmaßnahmen für die Kommunikation mit der Außenwelt hängt viel davon ab, mit welchen Gegenstellen - das können Server oder Clients sein) das Gerät sprechen muss.

Agiert das Gerät als Server, zum Beispiel indem es selbst ein Web-Interface über einen integrierten Webserver anbietet, kann es mit einem minimalen Satz an Algorithmen und Protokollen ausgestattet werden. Damit bleibt der Speicherbedarf möglichst gering.

Im umgekehrten Fall, also wenn das Gerät als Client agiert, hängt viel davon ab, mit welchen Servern das Gerät kommunizieren soll. Bei einer direkten Verbindung zum Server des Herstellers, kann dieser die Anzahl der installierten Algorithmen auf die tatsächlich verwendeten minimieren. Dies hat allerdings zur Folge, dass bei einem Wechsel der Algorithmen sofort ein Firmware-Update des Clients erforderlich ist. Ein Wechsel der Algorithmen kann zum Beispiel dann nötig sein, wenn diese nicht mehr als sicher gelten und daher durch andere ersetzt werden. Wenn der Client nicht permanent online ist, muss sichergestellt werden, dass der Client das Update auch nach eventueller Umstellung noch erhält.

Die Auswahl der Algorithmen wird auch davon bestimmt, welche Rechenleistung zur Verfügung steht und ob der Mikrocontroller hardwareseitige Beschleunigung für die verwendeten Algorithmen einsetzen kann. 

Open-Source-Community oder kommerzielle Lösung?


Gerade im Embedded Bereich sind kommerzielle Algorithmen interessant, da die frei verfügbaren Algorithmen in der Regel nicht auf die speziellen Bedürfnisse von Mikrocontroller-basierten Embedded-Systemen ausgerichtet sind. Meist sind diese auf und für Desktop-Systeme entwickelt und benötigen entsprechend viel Speicher. Der Einsatz solcher Lösungen wirft dann schnell die Frage auf, »reicht ein Mikrocontroller-System oder muss ein Mikroprozessor mit großem externem Speicher verwendet werden?« 

Selbstverständlich ist es erforderlich, dass die Algorithmen im Source-Code verfügbar sind. Es sollte also darauf geachtet werden, dass man auch bei kommerziellen Angeboten den vollständigen Source-Code erhalten kann. Gerade im Bereich Sicherheit ist es unabdinglich, dass der Gerätehersteller nicht mit einer Blackbox arbeitet, sondern genau verfolgen kann, was passiert. Allerdings sollte auch jemand dafür verantwortlich sein, den Source-Code aktuell zu halten und zu pflegen. Bei kommerziellen Lösungen steht der Anbieter dafür ein, seine Software zu pflegen. Bei Open-Source-Lösungen versucht die Open-Source-Community – im Folgenden einfach Community – dieses zu gewährleisten.

Im Bereich Desktop-Systeme wird das durchaus auch erfolgreich angewendet, ohne dass hier eine Verpflichtung also auch keine Verantwortlichkeit besteht. Für Desktop-Systeme ist die Community allerdings vergleichsweise groß. So spannend die Embedded-Industrie ist, sie ist immer noch eine hoch spezialisierte Nische. Die Community hat dadurch noch nicht die nötige Größe, um Sicherheitsalgorithmen zuverlässig, zeitnah und performant zu pflegen.

Das wird sich auch in absehbarer Zeit nicht ändern, da der hohe Bedarf an Entwicklern für Embedded Systeme sich nicht mit der Anzahl der Auszubildenden und Hochschulabgänger decken lässt.

Abseits von SSL/TLS kann es auch erforderlich sein, proprietäre Protokolle zu verwenden. So sind in einigen Bereichen wie zum Beispiel Home-Automation die Transportwege noch nicht standardisiert. Ein proprietäres Protokoll kann den Speicher- und Performance-Bedarf gegenüber SSL/TLS reduzieren. Wichtig bleibt jedoch die Sorgfalt bei der Konzeption des Protokolls. In Gesprächen mit Kunden hört man als Anbieter häufig, dass ein unbekanntes Protokoll sicherer ist, als ein bekanntes Protokoll. Das Gegenteil ist der Fall, gerade bekannte Protokolle haben den Vorteil, vielfach getestet zu sein. Wenn das System den Einsatz von SSL/TLS erlaubt, spricht daher viel dafür eben dieses Protokoll zu unterstützen. Ist dies nicht der Fall, werden Sicherheitsexperten benötigt, die genau wissen, worauf es ankommt, und Lücken erkennen können, bevor die ersten Angriffe das Gerät testen. 

Fazit

Die Lösung die aufgezeigten Problematiken sind hoch optimierte Software-Bibliotheken. Bei der TLS-Implementierung emSSL von Segger erfordern sowohl Client als auch Server minimalste Ressourcen wie zum Beispiel RAM. Bei nur 7 KB RAM-Bedarf lässt sich eine SSL-Verbindung auch auf Standard-Mikrocontrollern als Single-Chip-Lösung realisieren, die zudem noch eine hohe Performance aufweist. Zusätzlich existiert eine Kryptographie-Bibliothek emCrypt (Bild 2), die die Grundlage für alle Sicherheitsprotokolle von Segger bildet und auch für weitere Sicherheitsbedarfe außerhalb der Kommunikation eingesetzt werden kann. (fr)