Reihe: Embedded World – Die unsichtbaren Gehirne verstehen (Teil 11)

Sicherheit in der Zwangsjacke – Die besonderen Herausforderungen für Embedded Security

Von DerSchneider


Einleitung: Die verwundbare Unsichtbarkeit

In den vorherigen Artikeln haben wir Embedded Systems als stille, zuverlässige Helfer kennengelernt. Sie regeln unsere Motoren, steuern unsere Herzschrittmacher, öffnen unsere Türen. Wir vertrauen ihnen blind – oft über Jahrzehnte hinweg, ohne je ein Update einzuspielen, ohne je einen Gedanken an ihre Sicherheit zu verschwenden.

Dieses Vertrauen ist gefährlich. Embedded Systems sind heute eines der größten Sicherheitsrisiken unserer digitalen Welt. Sie sind überall, sie sind schwer zu patchen, und sie sind oft mit erschreckend naiven Sicherheitskonzepten entwickelt worden. Die Waschmaschine, die man über das Internet ausschalten kann, ist ärgerlich. Der Herzschrittmacher, den ein Angreifer manipulieren kann, ist tödlich.

Dieser Artikel widmet sich den besonderen Herausforderungen der Embedded Security. Wir erkunden, warum Sicherheit in eingebetteten Systemen so viel schwieriger ist als auf dem PC, welche Angriffsvektoren es gibt und wie man Systeme schützen kann, die jahrelang ohne menschliches Zutun funktionieren müssen.


Hauptteil

1. Die andere Welt: OT vs. IT

Um die Sicherheitsproblematik zu verstehen, muss man den fundamentalen Unterschied zwischen IT (Informationstechnologie) und OT (Operationstechnologie) verstehen.

AspektIT (PC, Server)OT (Embedded, Industrie)
PrioritätVertraulichkeitVerfügbarkeit
Lebensdauer3-5 Jahre10-20 Jahre
UpdatesRegelmäßigSelten bis nie
Phys. SchutzGeschlossene RäumeOft öffentlich zugänglich
RessourcenReichlichExtrem knapp
AusfallfolgeProduktivitätsverlustMenschenleben, Umweltschäden

Ein PC, der ausfällt, ist ärgerlich. Ein Steuergerät in einem Kraftwerk, das ausfällt, ist eine Katastrophe. Deshalb wird in der OT-Welt alles getan, um Verfügbarkeit zu garantieren – oft auf Kosten der Sicherheit.

2. Die Bedrohungslandschaft

Embedded Systems sind einer Vielzahl von Bedrohungen ausgesetzt:

Remote-Angriffe über Netzwerk: Viele Embedded Systeme sind vernetzt – via Ethernet, WLAN, Mobilfunk. Ein Angreifer, der Zugang zum Netzwerk findet, kann versuchen, das System zu übernehmen.

Physikalische Angriffe: Anders als Server im Rechenzentrum sind Embedded Systems oft öffentlich zugänglich. Ein Parkscheinautomat, ein Ladesäulen-Terminal, ein Smart-Home-Gerät – jeder kann sie anfassen, aufschrauben, Sonden anlegen.

Side-Channel-Angriffe: Eine besonders raffinierte Klasse von Angriffen nutzt nicht die Software, sondern physikalische Nebeneffekte: Stromverbrauch, elektromagnetische Abstrahlung, Laufzeitunterschiede. Daraus lassen sich geheime Schlüssel extrahieren.

Firmware-Extraktion: Wer physischen Zugriff hat, kann oft den Speicherchip auslesen und die Firmware analysieren – nach Schwachstellen suchen, geheime Schlüssel finden, das System reverse-engineeren.

Supply-Chain-Angriffe: Die Firmware kommt von irgendwoher. Wer manipuliert sie auf dem Weg vom Entwickler zum Gerät? Werden die Chips vielleicht schon bei der Herstellung mit Hintertüren versehen?

3. Die Zwangsjacke: Beschränkungen der Embedded Security

Embedded-Sicherheit ist keine einfache Portierung von PC-Sicherheitskonzepten. Die Rahmenbedingungen sind fundamental anders:

Ressourcenknappheit: Verschlüsselung kostet Rechenzeit und Speicher. Ein 8-Bit-Mikrocontroller mit 2 KB RAM kann kein SSL/TLS. Er kann oft nicht einmal RSA. Leichte Algorithmen wie AES sind machbar, aber auch sie kosten wertvolle Ressourcen.

Echtzeitanforderungen: Verschlüsselung dauert. Wenn ein Airbag innerhalb von Millisekunden auslösen muss, bleibt keine Zeit für aufwendige kryptografische Prüfungen.

Lange Lebensdauer: Ein Embedded System, das heute entwickelt wird, muss vielleicht 2035 noch sicher sein. Welche Verschlüsselung ist dann noch sicher? Welche Angriffe wird es dann geben? Man weiß es nicht.

Keine Updates: Viele Embedded Systems sind nie für Updates vorgesehen. Sie werden einmal programmiert und dann für ihr ganzes Leben sich selbst überlassen. Ein entdecktes Sicherheitsloch bleibt für immer offen.

Heterogenität: Es gibt Tausende verschiedener Mikrocontroller, Betriebssysteme, Konfigurationen. Sicherheitslösungen müssen für jede Plattform angepasst werden.

4. Die Grundprinzipien: Defense in Depth

Angesichts dieser Schwierigkeiten ist die einzige erfolgversprechende Strategie „Defense in Depth“ – mehrschichtige Verteidigung. Man vertraut keiner einzelnen Schutzmaßnahme, sondern baut mehrere, unabhängige Barrieren auf:

  1. Physikalische Sicherung: Gehäuse, die Manipulation erschweren, Sensoren, die Öffnung erkennen, Löschung sensibler Daten bei Angriff.
  2. Hardware-Sicherheit: Spezielle sichere Speicherbereiche, Hardware-Verschlüsselung, Zufallszahlengeneratoren, Schutz vor Side-Channel-Angriffen.
  3. Sicherer Boot: Nur signierte Firmware wird ausgeführt. Jede Stufe prüft die nächste, von der Hardware bis zum Betriebssystem.
  4. Speicherschutz: Getrennte Adressräume, Schutz vor Pufferüberläufen, Ausführungssperre für Datenbereiche.
  5. Kommunikationssicherheit: Verschlüsselung aller externen Verbindungen, Authentifizierung der Gegenstellen, Schutz vor Replay-Angriffen.
  6. Updates: Mechanismen für sichere Firmware-Updates, auch über das Netzwerk (Over-the-Air, OTA).
  7. Monitoring: Erkennung von Angriffen im laufenden Betrieb, Protokollierung, Alarmierung.

5. Sicheres Booten: Die Vertrauenskette

Sicheres Booten (Secure Boot) ist das Fundament jeder Embedded-Sicherheit. Das Prinzip: Jede Stufe des Bootvorgangs prüft die nächste, bevor sie ihr vertraut.

  • Stufe 0 (Hardware): Ein kleiner, unveränderlicher Code im ROM prüft die Signatur des Bootloaders.
  • Stufe 1 (Bootloader): Der Bootloader prüft die Signatur des Betriebssystems.
  • Stufe 2 (Betriebssystem): Das Betriebssystem prüft die Signatur der Anwendungen und Treiber.

Wenn irgendeine Prüfung fehlschlägt, wird nicht gebootet. So kann keine manipulierte Software gestartet werden.

Die Schlüssel für diese Prüfungen sind in der Hardware verankert – oft in speziellen, auslesegeschützten Registern. Selbst wenn jemand den Speicher ausliest, kann er die Schlüssel nicht extrahieren.

6. Verschlüsselung in der Zwangsjacke

Verschlüsselung auf schwacher Hardware ist eine Kunst für sich. Man muss Algorithmen wählen, die sicher und trotzdem effizient sind:

Symmetrische Verschlüsselung (AES): Relativ effizient in Hardware und Software. Gut geeignet für die meisten Embedded-Anwendungen. Viele Mikrocontroller haben AES-Hardwarebeschleuniger.

Asymmetrische Verschlüsselung (RSA, ECC): Rechenintensiv. ECC (Elliptic Curve Cryptography) ist deutlich effizienter als RSA bei gleicher Sicherheit und daher die bessere Wahl für Embedded.

Hash-Funktionen (SHA-256): Für Signaturen und Integritätsprüfungen. Auch hier haben viele Mikrocontroller Hardware-Unterstützung.

Leichtgewicht-Kryptografie: Spezielle Algorithmen für extrem ressourcenbeschränkte Umgebungen, oft im Rahmen von Standards wie ISO/IEC 29192 entwickelt.

7. Physikalische Angriffe und Gegenmaßnahmen

Embedded Systems sind physisch angreifbar. Einige Angriffsarten:

Invasive Angriffe: Das Gehäuse wird geöffnet, der Chip unter dem Mikroskop untersucht, Schichten abgetragen, Leitungen kontaktiert. Das ist aufwendig, teuer, aber möglich. Gegenmaßnahmen: Schutzschichten, die bei Angriff zerbrechen, Verdrahtung, die Manipulation erkennt.

Semi-invasive Angriffe: Laser oder Ionenstrahlen beeinflussen den Chip, ohne ihn komplett zu zerstören. Gegenmaßnahmen: Sensoren, die Bestrahlung erkennen, redundante Schaltungen.

Side-Channel-Angriffe: Analyse von Stromverbrauch, elektromagnetischer Abstrahlung, Laufzeit. Daraus lassen sich Schlüssel extrahieren. Gegenmaßnahmen: Konstantzeit-Algorithmen, Rauschen einstreuen, Stromverbrauch ausgleichen.

Fault-Injection-Angriffe: Spannungs- oder Taktimpulse erzeugen gezielte Fehler im Chip, die zu falschen Entscheidungen führen. Gegenmaßnahmen: Sensoren für Spannungs- und Taktabweichungen, redundante Berechnungen.

8. Updates – Das ungelöste Problem

Das größte Sicherheitsproblem vieler Embedded Systems ist die fehlende Update-Fähigkeit. Ein PC bekommt regelmäßig Patches. Ein Embedded System oft nicht.

Warum?

  • Es war nie dafür ausgelegt.
  • Die Kommunikationsschnittstelle fehlt.
  • Die Update-Infrastruktur kostet Geld.
  • Zertifizierungen (z.B. in der Medizintechnik) müssen nach jedem Update wiederholt werden.
  • Der Nutzer soll nicht eingreifen können (Angst vor Manipulation).

Dabei wären Updates so wichtig. Einmal entdeckte Sicherheitslücken bleiben sonst für immer offen.

Lösungsansätze:

  • Over-the-Air (OTA) Updates: Drahtlose Updates für IoT-Geräte. Technisch machbar, organisatorisch aufwendig.
  • Dual-Banking: Zwei Speicherbereiche für Firmware. Eine läuft, die andere wird aktualisiert. Bei Fehlern kann zurückgeschaltet werden.
  • Signierte Updates: Nur Updates mit gültiger Signatur werden akzeptiert.
  • Rollback-Schutz: Ältere, unsichere Versionen können nicht wieder eingespielt werden.

9. Ein Praxisbeispiel: Der vernetzte Stromzähler

Stellen wir uns einen modernen Stromzähler vor. Er misst den Verbrauch, sendet Daten an den Netzbetreiber, empfängt vielleicht Tarifinformationen. Ein ideales Angriffsziel:

  • Manipulation: Ein Angreifer möchte den Zähler langsamer laufen lassen, um Strom zu sparen.
  • Datenspionage: Wer möchte nicht wissen, wann jemand zu Hause ist?
  • Netzangriff: Der Zähler als Einfallstor ins Netz des Netzbetreibers.

Die Sicherheitsanforderungen:

  • Sicheres Booten, damit keine manipulierte Firmware läuft.
  • Verschlüsselte Kommunikation mit dem Netzbetreiber.
  • Physikalische Manipulationserkennung (Öffnungssensor löscht Schlüssel).
  • Regelmäßige signierte Updates.
  • Getrennte Bereiche für Messung, Kommunikation und Konfiguration.

Das alles mit einem Mikrocontroller, der vielleicht 1 Euro kostet und jahrelang ohne Wartung auskommen muss.

10. Die menschliche Komponente

Die größte Sicherheitslücke sind oft nicht die Chips, sondern die Menschen:

  • Standard-Passwörter: admin/admin, die nie geändert werden.
  • Hard-coded Keys: Schlüssel, die fest im Quellcode stehen und bei jedem Gerät gleich sind.
  • Fehlende Schulung: Entwickler, die Sicherheit nicht als Teil ihrer Aufgabe sehen.
  • Zeitdruck: „Erst funktionieren, Sicherheit später“ – später kommt nie.

Sicherheit muss von Anfang an mitgedacht werden. Sie ist kein Feature, das man nachrüsten kann. Sie ist eine Haltung, eine Denkweise, die den gesamten Entwicklungsprozess durchziehen muss.


Fazit und Ausblick

Embedded Security ist eine der größten Herausforderungen unserer digitalen Zeit. Milliarden von Geräten sind im Feld, viele davon unsicher, viele davon ohne Update-Möglichkeit, viele davon in kritischen Infrastrukturen. Die Angreifer schlafen nicht, und die Werkzeuge werden immer besser.

Die gute Nachricht: Es gibt Lösungen. Sicheres Booten, Verschlüsselung, Hardware-Sicherheitsmodule, Defense in Depth – all das ist technisch machbar. Es kostet Geld, es kostet Entwicklungszeit, es kostet Ressourcen. Aber im Vergleich zu den möglichen Schäden ist es gut investiertes Geld.

Doch die beste Technik nützt nichts, wenn die Menschen sie nicht anwenden. Sicherheit ist eine Frage der Ausbildung, der Unternehmenskultur, des Bewusstseins.

Im nächsten und letzten Block unserer Serie verlassen wir die reine Technik und wenden uns den Anwendungen zu. Wo begegnen uns Embedded Systems im Alltag? Welche Rolle spielen sie in Autos, in der Medizin, in der Industrie?

Mit diesen Anwendungen beschäftigen wir uns in den nächsten Artikeln.

Kommentar abschicken