Dipl.-Inform. Carsten Eilers

Der Vortrag von Lucas Apa und Carlos Mario Penagos von IOActive über Angriffe auf Industriesteuerungen über deren drahtlose Kommunikationsverbindungen hatte den Titel "Compromising Industrial Facilities From 40 Miles Away". Auch dieser Text basiert auf den dort vorgestellten und im Whitepaper beschriebenen Problemen.

Wie schon in der vorigen Folge zu sehen war ist es mit der Sicherheit der Verschlüsselung durch die Funk-Module nicht besonders weit her. Sofern die verwendeten Schlüssel vom Hersteller des Funk-Moduls oder der Industriesteuerung in der Firmware gespeichert werden muss ein Angreifer nur ein Gerät vom gleichen Hersteller mit der gleichen Firmware kaufen, um an den immer gleichen Schlüssel zu gelangen. Und damit kann er dann alle anderen Geräte mit dieser Firmware angreifen. Dafür muss er nicht mal den Schlüssel auslesen, es reicht, wenn er das Funk-Modul über USB ansteuert und zum Senden und Empfangen seiner bösartigen Kommunikation verwendet- die Ver- und Entschlüsselung erfolgt dann ganz automatisch mit dem vom Hersteller integrierten Schlüssel.

Es ist also deutlich sicherer, die Protokolle der höheren Schichten zur Absicherung der Kommunikation zu verwenden. Mit denen kann der Betreiber der Industriesteuerungen dann auch eigene Schlüssel, Zertifikate etc. verwenden, die keinem Dritten bekannt sind.

Die Schlüsselverteilung von ZigBee

Eines der für solche Zwecke verwendeten Systeme ist ZigBee, ein auf IEEE 802.15.4 aufbauender Standard zur drahtlosen Machine-to-Machine (M2M) Kommunikation auf Kurzstrecken (= 10 bis 100 Meter). ZigBee verwendet für die Verteilung von Schlüsseln und die Zugriffskontrolle vertrauenswürdige Geräte, die dem Konzept des Trust Center folgen.

Das Trust Center speichert die Schlüssel des Netzwerks, verwendet Security Services um ein Device mit seinem Schlüssel bzw. seinen Schlüsseln zu konfigurieren und es im Netzwerk zu autorisieren. Außerdem erzeugt es in regelmäßigen Abständen einen neuen Network Key (Netzwerkschlüssel) und sendet ihn, verschlüsselt mit dem bisherigen Network Key, als Broadcast an alle Devices.

Für jede Transaktion verwenden die beiden Kommunikationsteilnehmer, genannt Originator und Recipient, den gleichen symmetrischen Schlüssel. Für die Verteilung dieser Schlüssel an die Geräte stehen zwei Möglichkeiten zur Verfügung: Die Schlüssel können als Pre-Installation Keys vor der Ausrollung im Flash-Speicher der Geräte gespeichert werden, oder sie können während des Betriebs Over-the-Air (OTA) vom Trust Center an die Geräte gesendet werden. Sofern vorher kein anderes Secret zwischen Trust Center und Gerät ausgetauscht wurden, werden die Schlüssel als Klartext übertragen.

ZigBee verwendet drei Arten von Schlüsseln:

1. Der Link Key (Verbindungsschlüssel) sichert die Unicast-Kommunikation zwischen zwei Geräten. Die Verschlüsselung erfolgt auf den Application Support Sub Layer des ZigBee-Stacks. Eines der Geräte ist normalerweise das Trust Center, dessen Rolle über einen Key Establishment Service dynamisch vergeben wird.
2. Der Network Key (Netzwerkschlüssel) sichert die Broadcast-Kommunikation und ist ein für alle Geräte im Netzwerk identischer 128-Bit-Schlüssel.
   Wird dieser Schlüssel bei der Installation im Flash-Speicher gespeichert, wird er beim Booten des Geräts ins RAM kopiert. Ein Angreifer, der sich ein Gerät beschafft, kann diesen Schlüssel auf verschiedenen Wegen ausspähen.
   Handelt es sich um einen OTA-Schlüssel, wird der nur im "High Security"-Modus verschlüsselt übertragen, normalerweise erfolgt die Übertragung als Klartext. Gibt sich ein Gerät als Netzwerk-Node aus, kann es diesen Schlüssel ausspähen. Dann nützt es auch nicht viel, dass der Schlüssel regelmäßig ausgetauscht wird - der Angreifer muss seinen Angriff nur wiederholen.
3. Der Master Key (Hauptschlüssel) dient als anfängliches Shared Secret zwischen zwei Geräten, wenn sie über eine Key Establishment Procedure (SKKE) ihre Link Keys aushandeln.

ZigBees Verschlüsselungsfunktionen und ZigBee selbst enthalten noch eine Reihe weiterer Schwachstellen bzw. Probleme, auf die ich evtl. später noch eingehen werde. Für die von Lucas Apa und Carlos Mario Penagos beschriebenen Angriffe reichen schon die in dieser und der vorherigen Folge vorgestellten Schwachstellen und Probleme rund um die Schlüssel und ihre Verteilung aus. Wie, wird in der nächsten Folge beschrieben.

Carsten Eilers

---

Übersicht über alle Artikel zum Thema

Die Heimautomation auf Sicherheitskonferenzen - als Thema, nicht im Einsatz

SCADA-Systeme und Industriesteuerungen auf den Sicherheitskonferenzen ab 2010

SCADA-Systeme und Industriesteuerungen auf den Sicherheitskonferenzen ab 2011

SCADA-Systeme und Industriesteuerungen auf den Sicherheitskonferenzen ab 2012

SCADA-Systeme und Industriesteuerungen auf den Sicherheitskonferenzen ab 2013

SCADA-Systeme und Industriesteuerungen auf den Sicherheitskonferenzen ab 2013, Teil 2

SCADA-Systeme und Industriesteuerungen auf den Sicherheitskonferenzen ab 2013, Teil 3

SCADA-Systeme und Industriesteuerungen auf den Sicherheitskonferenzen ab 2013, Teil 4

SCADA-Systeme und Industriesteuerungen auf den Sicherheitskonferenzen ab 2013, Teil 5

SCADA-Systeme und Industriesteuerungen auf den Sicherheitskonferenzen ab 2013, Teil 6

SCADA-Systeme und Industriesteuerungen auf den Sicherheitskonferenzen ab 2013, Teil 7

SCADA-Systeme und Industriesteuerungen auf den Sicherheitskonferenzen ab 2013, Teil 8

SCADA-Systeme und Industriesteuerungen auf den Sicherheitskonferenzen ab 2013, Teil 9

SCADA-Systeme und Industriesteuerungen auf den Sicherheitskonferenzen 2014, Teil 1

SCADA-Systeme und Industriesteuerungen auf den Sicherheitskonferenzen 2014, Teil 2

SCADA-Systeme und Industriesteuerungen auf den Sicherheitskonferenzen 2014, Teil 3

SCADA-Systeme und Industriesteuerungen auf den Sicherheitskonferenzen 2014, Teil 4

SCADA-Systeme und Industriesteuerungen auf den Sicherheitskonferenzen 2014, Teil 5