Secure Embedded Software

Das Wichtigste in Kürze

Was bedeutet Secure Embedded Software?

Secure Embedded Software umfasst alle Maßnahmen in der Gerätesoftware, die verhindern sollen, dass ein eingebettetes System ungewollt gesteuert, verändert, ausgelesen oder gestört wird. Der Begriff bezieht sich nicht nur auf einzelne Verschlüsselungsfunktionen, sondern auf das Zusammenspiel aus Softwarearchitektur, Schnittstellenverhalten, Update-Mechanismus, Rechteverwaltung, Datenspeicherung und Diagnosezugängen.

In einem Embedded-Projekt beginnt Secure Embedded Software bereits bei der Frage, welche Funktionen ein Gerät ausführt und welche Folgen eine Manipulation hätte. Ein Steuergerät hat andere Schutzanforderungen als ein HMI-System, ein Messgerät oder ein Gateway. Bei einem Gateway stehen oft Kommunikationswege, Protokollübergänge und Zugriffsregeln im Vordergrund. Bei einem Messgerät können Messdaten, Konfigurationswerte und Kalibrierinformationen im Fokus stehen. Bei einer vernetzten Maschine geht es zusätzlich um Betriebszustände, Fernzugriff, Servicefunktionen und mögliche Auswirkungen auf angeschlossene Komponenten.

PICKPLACE betrachtet Secure Embedded Software als technischen Teil des Entwicklungsprozesses. Dabei wird geklärt, welche Angriffsflächen vorhanden sind, welche Schnittstellen abgesichert werden müssen und welche Sicherheitsfunktionen in der Software umgesetzt werden können. Dazu gehören zum Beispiel Authentisierung, Rechteprüfung, Integritätsprüfung, signierte Firmware-Pakete, abgesicherte Kommunikationskanäle und ein kontrollierter Umgang mit vertraulichen Daten.

Ein typisches Projekt kann mit einer Analyse vorhandener Software beginnen. Dabei werden Schnittstellen, Boot-Verhalten, Update-Abläufe, Speicherbereiche, Konfigurationsdateien, Servicefunktionen und Debug-Zugänge geprüft. Anschließend wird entschieden, welche Maßnahmen auf der bestehenden Plattform machbar sind und welche Änderungen an Softwarestruktur, Build-Prozess oder Gerätearchitektur erforderlich werden. Bei Neuentwicklungen kann der Schutzbedarf früher berücksichtigt werden, etwa durch eine Trennung von Rollen, klare Zuständigkeiten für sicherheitsbezogene Komponenten und definierte Zustandsübergänge.

Secure Embedded Software ist außerdem eng mit Hardware und Betriebskontext verbunden. Eine Software kann nur das schützen, was die Plattform unterstützt und was im späteren Betrieb kontrollierbar bleibt. Wenn ein Gerät physisch zugänglich ist, müssen andere Annahmen getroffen werden als bei einem geschlossen verbauten Steuergerät. Wenn Wartung über USB oder Netzwerk vorgesehen ist, müssen diese Wege in das Sicherheitskonzept einbezogen werden. Wenn Updates im Feld erfolgen sollen, muss die Software erkennen können, ob ein Update-Paket zur Gerätevariante passt und unverändert eingespielt wird.

Warum muss Software in einem Gerät geschützt werden?

Software in einem Gerät muss geschützt werden, weil sie die Funktionen des Geräts steuert, Daten verarbeitet und oft Zugriff auf Schnittstellen hat, die von außen erreichbar sind. Sobald ein Gerät über Netzwerk, USB, Funk, Diagnose oder Servicezugänge angesprochen werden kann, entsteht eine Angriffsfläche. Auch Schnittstellen, die nur für Wartung oder Fertigung gedacht sind, können später ein Risiko darstellen, wenn sie nicht kontrolliert werden.

Ein ungeschütztes Gerät kann auf unterschiedliche Weise betroffen sein. Konfigurationswerte können verändert werden, sodass das Gerät falsche Entscheidungen trifft oder Daten anders verarbeitet als vorgesehen. Firmware kann ausgetauscht oder verändert werden, wodurch nicht mehr nachvollziehbar ist, welche Software tatsächlich läuft. Zugänge können missbraucht werden, wenn Passwörter, Schlüssel oder Token unzureichend verwaltet werden. Kommunikationsdaten können mitgelesen oder manipuliert werden, wenn Protokolle keine geeigneten Schutzmechanismen verwenden.

Für ein Projekt bedeutet das: Der Schutz der Software muss aus den konkreten Funktionen und Schnittstellen abgeleitet werden. Es reicht nicht, einzelne Funktionen nachträglich zu ergänzen, wenn grundlegende Annahmen in der Architektur nicht passen. Wenn ein Gerät mehrere Rollen unterstützt, etwa Bediener, Service, Fertigung und Entwicklung, muss festgelegt werden, welche Rolle welche Aktionen ausführen darf. Wenn ein Gerät Daten speichert, muss entschieden werden, welche Daten vor Veränderung, Auslesen oder Wiederverwendung geschützt werden müssen. Wenn ein Gerät aktualisiert wird, muss feststehen, wie die Herkunft und Integrität der Update-Dateien geprüft werden.

PICKPLACE klärt in solchen Projekten auch organisatorische Abhängigkeiten. Sicherheitsfunktionen betreffen nicht nur den Quellcode. Sie wirken sich auf Build-Prozesse, Schlüsselverwaltung, Testabläufe, Fertigung, Service und Dokumentation aus. Ein signiertes Update setzt beispielsweise voraus, dass klar geregelt ist, wer Update-Pakete erzeugt, wie Signaturen erstellt werden und wie die Software im Gerät diese Signaturen prüft. Ein Rechtekonzept setzt voraus, dass Rollen, Zugangsdaten und Serviceabläufe beschrieben sind. Ein Zugriffsschutz für Diagnosefunktionen setzt voraus, dass Diagnosewerkzeuge, Schnittstellenprotokolle und Berechtigungen zusammen betrachtet werden.

Ein weiterer Grund für Schutzmaßnahmen liegt in der Lebensdauer eingebetteter Systeme. Viele Geräte bleiben über längere Zeit im Einsatz und werden nicht ständig ausgetauscht. Dadurch müssen Update-Fähigkeit, Fehlerbehebung und spätere Änderungen berücksichtigt werden. Wenn ein Gerät im Feld aktualisiert werden kann, muss der Update-Prozess gegen falsche oder manipulierte Pakete abgesichert sein. Gleichzeitig muss die Software mit Abbrüchen, Stromverlust oder unvollständigen Übertragungen umgehen können, ohne unkontrollierte Zustände zu erzeugen.

Spoofing, Tampering, Denial-of-Service – was gibt es für Angriffe?

Bei Secure Embedded Software werden verschiedene Angriffsmuster betrachtet, weil sie unterschiedliche Schutzmaßnahmen erfordern. Spoofing bedeutet, dass sich ein Angreifer als berechtigter Teilnehmer, Dienst, Gerät oder Benutzer ausgibt. In einem Embedded-System kann das zum Beispiel ein gefälschter Kommunikationspartner im Netzwerk sein, ein unberechtigtes Servicewerkzeug oder ein Gerät, das eine fremde Identität nutzt. Gegen solche Angriffe helfen Authentisierung, geprüfte Geräteidentitäten, Zugriffskontrollen und Protokolle, die nicht allein auf leicht kopierbaren Kennungen beruhen.

Tampering beschreibt das Verändern von Software, Daten, Nachrichten oder Konfigurationswerten. Bei eingebetteten Geräten kann das eine manipulierte Firmware-Datei, eine geänderte Parametrierung, ein veränderter Messwert oder eine nachträglich modifizierte Nachricht sein. Maßnahmen dagegen sind Integritätsprüfungen, Signaturen, Prüfsummen mit geeignetem Schutzkontext, geschützte Speicherbereiche und klare Regeln, welche Daten wann geändert werden dürfen. Im Projekt muss festgelegt werden, an welchen Stellen Integrität geprüft wird: beim Booten, beim Update, beim Laden von Konfigurationsdaten, beim Empfang von Nachrichten oder bei sicherheitsrelevanten Zustandswechseln.

Denial-of-Service zielt darauf ab, ein Gerät oder einen Dienst nicht mehr verfügbar zu machen. Bei eingebetteten Systemen kann das durch zu viele Anfragen, fehlerhafte Datenpakete, blockierende Kommunikationszustände oder wiederholte Verbindungsaufbauten entstehen. Auch kleine Mikrocontroller oder Embedded-Linux-Systeme können betroffen sein, wenn Ressourcen wie CPU-Zeit, Speicher, Netzwerkpuffer oder Dateisystemzugriffe nicht begrenzt werden. Schutzmaßnahmen können Eingabevalidierung, Begrenzung von Anfragen, definierte Timeouts, Zustandsautomaten mit Fehlerpfaden und eine kontrollierte Behandlung fehlerhafter Nachrichten sein.

Neben diesen drei bekannten Mustern gibt es weitere Angriffspunkte, die in Embedded-Projekten häufig geprüft werden. Dazu gehören ungeschützte Debug-Schnittstellen, offene Servicezugänge, hart codierte Zugangsdaten, unsichere Standardkonfigurationen, unzureichend geprüfte Update-Pakete und Fehler in der Speicherbehandlung. Auch Diagnosefunktionen verdienen Aufmerksamkeit, weil sie oft tief in das Gerät eingreifen können. Wenn Diagnosebefehle Konfigurationswerte ändern, Speicher lesen oder Betriebszustände beeinflussen, müssen sie in das Rechte- und Zugriffskonzept aufgenommen werden.

PICKPLACE betrachtet solche Angriffsmuster nicht abstrakt, sondern bezogen auf das konkrete Gerät. Ein Gerät ohne Funkmodul hat andere Angriffswege als ein Gateway mit mehreren Netzwerksegmenten. Ein HMI-System mit Benutzerverwaltung hat andere Anforderungen als ein Messmodul ohne lokale Bedienung. Für die Umsetzung wird deshalb geklärt, welche Schnittstellen real vorhanden sind, welche im Feld zugänglich bleiben, welche nur in Fertigung oder Service genutzt werden und welche Funktionen bei Fehlbedienung oder Missbrauch kritische Auswirkungen haben können.

Typische Ausgangslagen in Secure-Embedded-Software-Projekten

Secure-Embedded-Software-Projekte entstehen häufig in unterschiedlichen Phasen eines Produktlebenszyklus. Bei Neuentwicklungen geht es darum, Schutzfunktionen von Beginn an in Architektur und Implementierung einzubinden. Bei bestehenden Geräten steht oft die Bewertung der aktuellen Software im Vordergrund. Dabei wird geprüft, welche Zugänge existieren, welche Sicherheitsannahmen bisher gelten und welche Teile der Software angepasst werden müssen.

Eine weitere Ausgangslage ist die Anbindung eines bisher isolierten Geräts an ein Netzwerk oder eine Serviceplattform. Wenn ein Gerät früher nur lokal bedient wurde und später Fernzugriff, Datenübertragung oder zentrale Updates erhalten soll, verändern sich die Anforderungen. Funktionen, die im isolierten Betrieb unkritisch waren, können bei externer Erreichbarkeit neu bewertet werden. Dazu zählen Konfigurationsschnittstellen, Protokolldienste, Logausgaben und Diagnosekommandos.

Auch Redesigns oder Plattformwechsel führen zu Sicherheitsfragen. Wenn eine Software von einem Mikrocontroller auf eine andere Plattform übertragen wird oder wenn ein bestehendes System um ein Gateway ergänzt wird, müssen Speicherlayout, Startprozess, Update-Mechanik und Kommunikationswege neu betrachtet werden. Sicherheitsfunktionen lassen sich dabei nicht immer unverändert übernehmen, weil Hardwarefunktionen, Bootloader, Betriebssystem und Toolchain andere Eigenschaften haben.

Beispielhafte Software

• Security Stack Mbed TLS
• Security Stack wolfSSL
• Bootloader MCUboot
• RTOS SafeRTOS
• Software Update RAUC

Technische Abhängigkeiten und Schnittstellen

Secure Embedded Software hängt von mehreren technischen Ebenen ab. Auf der unteren Ebene stehen Bootloader, Speicherbereiche, Hardwarefunktionen und Schnittstellencontroller. Darüber liegen Betriebssystem, Treiber, Kommunikationsstacks, Applikationslogik und Servicefunktionen. Jede Ebene kann Schutzfunktionen unterstützen oder begrenzen.

Bei sicheren Updates muss zum Beispiel geklärt werden, wie Firmware-Pakete übertragen, gespeichert, geprüft und aktiviert werden. Die Software muss erkennen, ob ein Paket vollständig ist, ob es zur Gerätevariante passt und ob es unverändert vorliegt. Bei sicherer Kommunikation müssen Protokolle, Schlüsselmaterial, Zertifikate oder andere Identitätsinformationen verwaltet werden. Bei Zugriffsschutz müssen Rollen und Berechtigungen nicht nur in einer Oberfläche, sondern auch in den darunterliegenden Diensten geprüft werden.

Schnittstellen sind ein zentraler Teil der Betrachtung. Netzwerk, USB, Funk, serielle Diagnose, interne Busse und Serviceports unterscheiden sich in Reichweite, Bedienbarkeit und Risiko. Eine Schnittstelle, die in der Entwicklung offen genutzt wird, sollte für den späteren Betrieb bewertet werden. Dabei wird festgelegt, ob sie deaktiviert, eingeschränkt, authentisiert oder protokolliert werden muss.

Unsere Leistungen

PICKPLACE unterstützt Projekte zu Secure Embedded Software mit Secure Hardening, Software-Entwicklung und Sicherheitskonzepten. Der Leistungsumfang richtet sich nach dem vorhandenen System, der Projektphase und den erreichbaren Schnittstellen des Geräts.

Beim Secure Hardening analysieren wir bestehende Software und Geräteschnittstellen. Dazu gehören Kommunikationswege, Servicezugänge, Diagnosefunktionen, Update-Abläufe, Rechteprüfungen und Konfigurationsmechanismen. Aus den Ergebnissen werden konkrete Anpassungen abgeleitet, etwa strengere Eingabeprüfungen, begrenzte Zugriffe, deaktivierte Entwicklungsfunktionen im Betrieb, Prüfungen von Firmware-Paketen oder klarere Fehlerpfade bei ungültigen Daten.

In der Software-Entwicklung setzen wir sicherheitsbezogene Funktionen für eingebettete Systeme um oder erweitern vorhandene Komponenten. Das kann sichere Kommunikation, Signaturprüfung, Zugriffsschutz, Rollenlogik, Update-Handling, Integritätsprüfungen oder die Behandlung fehlerhafter Nachrichten betreffen. Dabei wird berücksichtigt, welche Ressourcen das Zielsystem hat und welche Funktionen auf Bootloader-, Betriebssystem- oder Applikationsebene umgesetzt werden müssen.

Bei Sicherheitskonzepten strukturieren wir Anforderungen, Angriffsflächen und technische Maßnahmen. Wir beschreiben, welche Schnittstellen geschützt werden, welche Rollen vorgesehen sind, wie Updates geprüft werden, welche Daten geschützt werden müssen und welche Grenzen das System hat. Ein solches Konzept dient als Grundlage für Entwicklung, Review, Test und Übergabe in die Umsetzung.

Zusätzlich unterstützen wir bei Fehleranalyse und Debugging, wenn sicherheitsrelevante Funktionen nicht wie vorgesehen arbeiten. Dazu zählen fehlgeschlagene Update-Prüfungen, Probleme mit Berechtigungen, unerwartete Verbindungsabbrüche, nicht nachvollziehbare Diagnosezugriffe oder fehlerhafte Zustände nach ungültigen Eingaben. Die Analyse verbindet Code, Schnittstellenverhalten und Gerätezustand, damit Ursachen eingegrenzt und Änderungen gezielt umgesetzt werden können.