Skip to content

Die IoT Top 10, #4: Fehlende Transportverschlüsselung

Bei der Beschreibung der gefährlichsten Schwachstellen in den Geräten des IoT gemäß den Top IoT Vulnerabilities von OWASP sind wir bei Punkt 4 angekommen: "Lack of Transport Encryption". Oder auf deutsch:

Fehlende Transportverschlüsselung

Eine fehlende Transportverschlüsselung bedeutet, dass die übertragenen Daten unterwegs belauscht und/oder manipuliert werden können. Das will man natürlich nicht, weshalb man die Daten während der Übertragung tunlichst verschlüsselt.

Dabei muss nicht nur der Zugriff auf die Weboberfläche geschützt werden (sinnvollerweise durch den Einsatz von TLS in Form von HTTPS), sondern auch die Kommunikation des IoT-Geräts mit einem zentralen Server bzw. "der Cloud", die Kommunikation der Mobile-App, und auch jede weitere Kommunikation, so es denn noch eine gibt.

Dabei reicht es nicht aus, einfach HTTPS einzuschalten bzw. SSL/TLS zu verwenden, dies muss auch sicher geschehen. So ist z.B. bei der Weboberfläche darauf zu achten, dass HTTPS durchgehend verwendet wird. Wird z.B. die Startseite über HTTP geladen und erst das darin befindliche Formular mit den Zugangsdaten über HTTPS an den Server oder das IoT-Gerät geschickt, kann ein Angreifer diese Seite so manipulieren, dass die Zugangsdaten unverschlüsselt und bei Bedarf auch an seinen Server geschickt werden. Und auch bei der Nutzung von Cookies muss darauf geachtet werden, dass diese nicht unverschlüsselt gesendet werden können.

Bei den Mobile-Apps ist es besonders wichtig, auf die Prüfung des vom Server oder IoT-Geräts präsentierten Zertifikats zu achten. Denn Apps fallen immer wieder negativ auf, weil sie die Zertifikate gar nicht oder nur unzureichend prüfen. Dann kann ein Man-in-the-Middle die HTTPS- bzw. allg. SSL/TLS-Verbindung problemlos aufbrechen, indem er ein selbst erstelltes gefälschtes Zertifikat präsentiert.

Bei Bedarf können geringe Datenmengen auch ohne den Aufwand des Aufbaus einer SSL/TLS-Verbindung vom IoT-Gerät an den zentralen Server geschickt werden, nur müssen sie dann natürlich separat verschlüsselt werden. In manchen Fällen ist es einfach leichter, die Daten mit einem zwischen Gerät und Server vereinbarten Schlüssel z.B. mit AES zu verschlüsseln und dann den Schlüsseltext an den Server zu schicken als erst eine SSL/TLS-Verbindung aufzubauen. Da nur das IoT-Gerät und der Server den individuellen Schlüssel kennen, dient die Entschlüsselung auf dem Server dann gleichzeitig als Nachweis der Authentizität - nur das IoT-Gerät konnte die Daten so verschlüsseln, dass der Server sie entschlüsseln kann.

Anforderungen an die Transportverschlüsselung

OWASP listet die folgenden Punkt als Anforderungen an eine ausreichende Transportverschlüsselung auf:

  1. Stellen Sie sicher, dass die Daten beim Transport über das Netz mit Protokollen wie SSL/TLS verschlüsselt werden.
  2. Steht SSL/TLS nicht zur Verfügung bzw. soll es nicht verwendet werden, müssen die Daten mit anderen Standard-Verschlüsselungsverfahren geschützt werden (oder mit anderen Worte: Denken Sie sich nicht selbst eine Verschlüsselung aus, in den allermeisten Fällen geht das in die Hose, deshalb auch die nächste Forderung).
  3. Verwenden Sie nur akzeptierte Verschlüsselungsstandards und vermeiden sie proprietäre Protokolle.
  4. Achten Sie darauf, dass die Payload der Nachrichten verschlüsselt werden.
  5. Achten Sie auf einen sicheren Handshake (s.o.: Eine fehlende Zertifikatsprüfung wird zu einem Einfallstor für einen MitM).
  6. Achten Sie darauf, dass die Integrität der empfangenen Daten geprüft wird.

Mit anderen Worten: Setzen Sie bewährte Krypto-Verfahren ein, und tun sie das sicher. So, wie man es allgemein erwartet, nicht nur im Bereich des IoT. Und achten Sie dabei auch auf die Schlüsselerzeugung, 2012 sind viele Embedded Devices (die man heute voll "IoT Devices" genannt hätte) negativ aufgefallen, weil sie unsichere RSA-Schlüssel verwendeten, die sich u.U. brechen ließen.

Soviel zum "Lack of Transport Encryption". In der nächsten Folge geht es um Punkt 5 der IoT-Top-10: "Privacy Concerns", also Gefahren für die Privatsphäre.

Carsten Eilers

Trackbacks

Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #6: Unsichere Cloud-Interfaces

Vorschau anzeigen
Bei der Beschreibung der gefährlichsten Schwachstellen in den Geräten des IoT gemäß den Top IoT Vulnerabilities von OWASP sind wir bei Punkt 6 angekommen: "Insecure Cloud Interface". Oder auf deutsch: Unsichere Cloud-Int

Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #7: Mobile Cloud-Interfaces

Vorschau anzeigen
Bei der Beschreibung der gefährlichsten Schwachstellen in den Geräten des IoT gemäß den Top IoT Vulnerabilities von OWASP sind wir bei Punkt 7 angekommen: "Insecure Mobile Interface". Oder auf deutsch: Unsichere Mobile-I