Sobald ein Embedded-Gerät ins Netzwerk kommt, ist es nicht mehr nur eine Maschine, sondern eine Tür. Jeder Sensor, Controller und jedes Gateway, das Daten senden oder empfangen kann, ist ein möglicher Zugang — für Angreifer, um Informationen zu stehlen, Befehle zu fälschen oder eine Maschine lahmzulegen. Im Consumer-IoT ist das ein Ärgernis; in Industrie, Medizin oder Infrastruktur kann es katastrophal sein. Und doch wird Embedded-Sicherheit noch zu oft als nachträglicher Aufsatz behandelt. Dieser Leitfaden nimmt das Thema von Grund auf auseinander, damit Sie am Ende nicht nur wissen, was zu tun ist, sondern auch warum jede Ebene existiert.

Warum Embedded-Sicherheit eine eigene Kategorie ist

Einen Laptop und einen Mikrocontroller abzusichern sind unterschiedliche Probleme. Embedded-Geräte tragen Einschränkungen, die jede Entscheidung prägen:

  • Begrenzte Ressourcen: wenig Speicher, bescheidene CPUs und enge Energiebudgets schließen schwere Sicherheitsstacks aus.
  • Sehr lange Lebensdauer: eine Maschinensteuerung läuft oft 15–20 Jahre, lange nachdem ihre Software nicht mehr gepflegt wird.
  • Physische Exposition: Geräte stehen im Feld, wo ein Angreifer sie berühren, öffnen und untersuchen kann.
  • Seltene Updates: viele Geräte wurden nie dafür entworfen, überhaupt gepatcht zu werden.
  • Reale Folgen: ein kompromittierter Aktuator verliert nicht nur Daten — er kann einen Motor bewegen, ein Ventil öffnen oder eine Linie stoppen.

Deshalb kann Embedded-Sicherheit kein einzelnes Produkt sein. Sie ist ein Satz von Ebenen, die jeweils eine andere Art von Angriff abdecken.

Die Bedrohungslage

Um gut zu verteidigen, muss man wissen, wogegen. Angriffe auf Embedded-Kommunikation fallen grob in einige Familien:

  • Abhören: Daten lesen, während sie über einen Bus oder ein Netzwerk reisen.
  • Spoofing und Injektion: sich als vertrautes Gerät ausgeben und gefälschte Befehle oder Daten senden.
  • Replay: eine legitime Nachricht aufzeichnen und später erneut senden, um eine Aktion auszulösen.
  • Man-in-the-Middle: unsichtbar zwischen zwei Geräten sitzen und ihr Gespräch lesen und verändern.
  • Denial of Service: ein Gerät fluten oder stören, bis es seine Aufgabe nicht mehr erfüllen kann.
  • Physische und Seitenkanal-Angriffe: Pins abgreifen, Busse mitschneiden oder Strom und Timing messen, um Geheimnisse zu gewinnen.

Jede Sicherheitsmaßnahme unten existiert, um eine oder mehrere dieser Türen zu schließen.

Die Ziele: was "sicher" wirklich bedeutet

Sicherheit wird oft durch die CIA-Trias zusammengefasst, für Embedded erweitert:

  • Vertraulichkeit — nur befugte Parteien können die Daten lesen.
  • Integrität — Daten können unterwegs nicht unbemerkt verändert werden.
  • Verfügbarkeit — das System funktioniert, wenn es gebraucht wird.
  • Authentizität — man kann beweisen, dass eine Nachricht wirklich vom angegebenen Gerät stammt.

Gute Kommunikationssicherheit liefert alle vier zugleich. Verschlüsselung allein etwa gibt Vertraulichkeit, sagt aber nichts über Authentizität — weshalb so viele "verschlüsselte" Systeme trotzdem leicht zu fälschen sind.

Ebene 1 — Ein Hardware-Vertrauensanker

Alles andere ruht auf einer Frage: Kann das Gerät sich selbst vertrauen? Ein Hardware-Vertrauensanker (Root of Trust) ist ein kleiner, manipulationssicherer Teil des Chips, dessen Verhalten Software nicht ändern kann. Er verankert zwei Grundlagen:

  • Secure Boot: beim Einschalten wird jede Firmware-Stufe kryptografisch geprüft, bevor sie läuft — eine Vertrauenskette ab einer unveränderlichen ersten Stufe. Wurde die Firmware manipuliert, verweigert das Gerät den Start.
  • Geschützte Schlüsselspeicherung: ein Secure Element, TPM oder der sichere Bereich des MCU speichert private Schlüssel, sodass sie den Chip nie lesbar verlassen — selbst wenn ein Angreifer das Gerät in der Hand hat.

Ohne dieses Fundament lässt sich jede höhere Sicherheit umgehen, indem man einfach die Software austauscht.

Ebene 2 — Kryptografie, die zu Embedded passt

Kryptografie ist der Werkzeugkasten, der sichere Kommunikation möglich macht. Das Wesentliche:

  • Symmetrische Verschlüsselung (z. B. AES): schnell und leicht, verschlüsselt den eigentlichen Datenstrom, sobald beide Seiten einen Schlüssel teilen.
  • Asymmetrische Kryptografie (z. B. ECC / RSA): authentifiziert Geräte und tauscht den symmetrischen Schlüssel sicher aus. ECC wird auf Embedded bevorzugt, da es starke Sicherheit mit kleinen Schlüsseln bietet.
  • Hashing und MACs (z. B. SHA-256, HMAC): beweisen, dass eine Nachricht nicht verändert wurde und — mit Schlüssel — dass sie von einem vertrauten Sender stammt.
  • Gute Zufälligkeit: Schlüssel sind nur so stark wie ihre Entropie; ein echter Hardware-Zufallszahlengenerator ist unverzichtbar.

Zwei Regeln zählen über allem: Erfinden Sie niemals eigene Kryptografie und nutzen Sie Hardware-Krypto-Beschleuniger, wo der Chip sie bietet, damit Sicherheit die Leistung nicht lähmt.

Ebene 3 — Daten während der Übertragung schützen

Hier lebt Kommunikationssicherheit im Alltag. Das Arbeitspferd ist TLS (und DTLS für UDP-basierte Verbindungen), das alle vier Ziele vereint: Es authentifiziert beide Enden, handelt frische Sitzungsschlüssel aus, verschlüsselt die Daten und erkennt Manipulation. Das entscheidende Detail bei Embedded ist die gegenseitige Authentifizierung: Nicht nur das Gerät prüft den Server, auch der Server prüft das Gerät — damit sich kein Betrüger ins Netz einklinkt. Je nach Ressourcen nutzt dies Zertifikate (PKI) oder vorab geteilte Schlüssel.

Über dem Transport hat jedes Protokoll seine eigene Sicherheitsgeschichte:

  • MQTT: sicher, wenn es über TLS mit Client-Zertifikaten läuft; für sich allein hat es keinerlei Schutz.
  • OPC UA: mit eingebauter Sicherheit entworfen — Signierung, Verschlüsselung und Authentifizierung sind Teil des Standards.
  • Modbus: die klassischen Varianten haben überhaupt keine Sicherheit; es muss durch TLS getunnelt oder in einem geschützten Netz isoliert werden.
  • CAN: herkömmliches CAN hat keine Authentifizierung; sicherheitskritische Systeme ergänzen eine Nachrichtenauthentifizierung (etwa CAN-Sicherheitserweiterungen).

Eine wiederkehrende Lehre: Viele Industrieprotokolle wurden für vertraute, isolierte Netze entworfen und sind unsicher, sobald sie exponiert werden. Zu erkennen, welches Protokoll schützt und welches nicht, ist die halbe Arbeit.

Ebene 4 — Identität und Schlüsselverwaltung

Kryptografie ist nur so stark wie die Verwaltung der Schlüssel dahinter. Hier scheitern viele Projekte still. Ein robuster Ansatz deckt das ganze Leben eines Schlüssels ab:

  • Provisionierung: jedes Gerät erhält in der Fertigung eine eindeutige Identität und Schlüssel, idealerweise auf dem Chip erzeugt, damit der private Schlüssel nie offengelegt wird.
  • Eine PKI: Zertifikate binden jede Identität an eine vertraute Instanz, sodass Geräte und Server einander prüfen können.
  • Rotation und Widerruf: Schlüssel lassen sich planmäßig ersetzen, und ein kompromittiertes Gerät kann aus dem Netz ausgeschlossen werden.
  • Sichere Speicherung: private Schlüssel liegen im Secure Element, nie im offenen Flash.

Geteilte, fest einkodierte Schlüssel über eine ganze Produktlinie sind einer der häufigsten und gefährlichsten Fehler — knackt man ein Gerät, knackt man alle.

Ebene 5 — Sichere Firmware-Updates (OTA)

Ein Gerät, das nicht aktualisiert werden kann, kann nicht sicher gehalten werden, denn Schwachstellen werden noch Jahre nach Auslieferung entdeckt. Doch der Update-Kanal ist selbst ein Hauptziel. Ein sicheres Over-the-Air-Update muss sein:

  • Signiert: das Gerät installiert Firmware nur mit gültiger Signatur des Herstellers.
  • Verschlüsselt: damit das Image unterwegs nicht gelesen und rückentwickelt werden kann.
  • Versionsgeschützt: Rollback-Schutz verhindert, dass ein Angreifer eine alte, verwundbare Version erzwingt.
  • Ausfallsicher: A/B-Partitionen oder ein Recovery-Image sorgen dafür, dass ein fehlgeschlagenes Update das Gerät nie unbrauchbar macht.

Ebene 6 — Defense in Depth und Segmentierung

Keine einzelne Maßnahme genügt; starke Systeme nehmen an, dass jede Ebene versagen kann. Netzwerk-Segmentierung teilt das Werk in Zonen, getrennt durch kontrollierte Verbindungen (Conduits), sodass ein Einbruch in einem Bereich nicht überspringt. Gateways und Firewalls filtern, was zwischen Zonen passieren darf, und Maschinen bleiben fern vom offenen Internet und von der Büro-IT. Der Industriestandard IEC 62443 formalisiert genau dieses Zonen-und-Conduits-Denken und ist die Referenz für industrielle Umgebungen.

Ebene 7 — Ein sicherer Entwicklungsprozess

Sicherheit ist ein Prozess, kein am Ende angehängtes Feature. Reife Teams bauen sie in ihre Arbeitsweise ein:

  • Bedrohungsmodellierung: vor dem Code fragen, was schiefgehen könnte und wer angreifen würde.
  • Least Privilege: jede Komponente erhält nur den Zugriff, den sie wirklich braucht.
  • Speichersichere Praxis: die meisten Embedded-Exploits stammen aus Speicherfehlern; sorgfältiges Coding, moderne Sprachen und statische Analyse reduzieren sie.
  • Tests: Penetrationstests und Fuzzing versuchen aktiv, das Gerät zu brechen, bevor es Angreifer tun.
  • Eine SBOM: eine Software-Stückliste erfasst jede Komponente, damit bekannte Schwachstellen schnell gefunden und behoben werden.

Standards und Regulierung, die man nicht ignorieren kann

Sicherheit wird zunehmend gesetzliche Pflicht, nicht nur gute Praxis. Wichtige Referenzen sind IEC 62443 für industrielle Systeme, ETSI EN 303 645 für Consumer-IoT, NIST-Leitlinien und — in Europa — der EU Cyber Resilience Act, der Sicherheitspflichten für Produkte mit digitalen Elementen verbindlich macht. Von Anfang an danach zu entwerfen spart teure Nachbesserungen.

Die häufigsten Fehler

  • Annehmen, das Netz sei vertrauenswürdig, und Protokolle ungeschützt lassen.
  • Fest einkodierte oder geteilte Passwörter und Schlüssel.
  • Verschlüsselung ohne Authentifizierung (oder umgekehrt).
  • Kein Plan, Geräte im Feld zu aktualisieren.
  • Eigene Kryptografie erfinden.
  • Sicherheit als letztes Häkchen statt als Designprinzip behandeln.

Eine praktische Start-Checkliste

  • Secure Boot und einen Hardware-Vertrauensanker aktivieren.
  • Schlüssel im Secure Element speichern; jedem Gerät eine eindeutige Identität geben.
  • Jede Kommunikation verschlüsseln und gegenseitig authentifizieren (TLS/DTLS).
  • Jedes Firmware-Update signieren und verschlüsseln, mit Rollback-Schutz.
  • Das Netzwerk segmentieren und Maschinen vom offenen Internet fernhalten.
  • Früh Bedrohungen modellieren und das fertige Gerät wie ein Angreifer testen.

Embedded-Sicherheit richtig machen

Echte Sicherheit ist kein einzelner cleverer Trick — sie ist das Zusammenspiel dieser Ebenen, jede passend zu den Einschränkungen des Geräts und der Realität der Umgebung gewählt. Gut gemacht ist sie unsichtbar: Das System funktioniert einfach, sicher, über seine gesamte lange Lebensdauer. Schlecht gemacht ist sie ein Risiko, das nur darauf wartet, entdeckt zu werden. Genau dieses End-to-End-Denken bringe ich in Embedded-Projekte ein — vom Hardware-Vertrauensanker bis zum letzten sicheren Update.

Wenn Sie vernetzte Geräte bauen oder betreiben und sie wirklich sicher entwickelt haben möchten — oder ein bestehendes System prüfen lassen wollen — nehmen Sie Kontakt auf, und wir besprechen Ihre Anforderungen.