Embedded-Systeme Wie sicher ist sicher genug?

Mit der Sicherheit ist es wie mit der Qualität: Sie lässt sich nicht ergänzen – sie muss nahtlos in ein Design eingewoben sein. Gleichzeitig sollen Entwickler Produkte entwickeln, die in einem immer vernetzteren und damit potenziell gefährlicheren Kontext funktionieren müssen. Ein Balanceakt.

Die Faustregel, dass Sicherheit dann gegeben ist, wenn mehr Aufwand erforderlich ist, um ein System zu kompromittieren, als der Angreifer Gewinn daraus ziehen könnte, verliert seine Gültigkeit mit zunehmender Konnek­tivität. So zieht ein Angreifer vielleicht
nur wenig Vorteile aus dem Zugriff auf die Hauptfunktion eines Embedded-Systems. Für Personen mit böswilliger Absicht können solche Systeme aber dennoch von Wert sein. Denn es sind Einfallstore, die dem Angreifer prinzi­piell Zugriff auf die lokale Netzwerkstruktur erlauben.

Das Problem der Sicherheit ist darüber hinaus multidimensional geworden. Da geht es zum einen um IP-Sicherheit, also die Frage, wie das Embedded-System selbst davor geschützt wird, dass der Code kopiert und das Design geklont wird. Zum anderen ist auch immer die vorgesehene Funktion der Systeme zu schützen. Das heißt, dass Design muss so aufgebaut sein, dass es nicht unterwandert oder auf unbeabsichtigte Art und Weise betrieben wird. Außerdem müssen die Daten, die das System verarbeitet, sowie die Angaben aller Benutzer gesichert werden. Und schlussendlich darf ein Angreifer das Embedded-System, wie bereits erwähnt, nicht als Einfallstor in die weitere IT-Infrastruktur nutzen können.

Neue Bedrohung: Cryptojacking

Als wäre das alles nicht genug, ist eine neue Bedrohung aufgetaucht: das »Cryptojacking«. Hierbei »stehlen« Angreifer Rechenzyklen aus einem System. Dazu wird ein Skript zum normalen Betrieb des Zielsystems hinzugefügt, das im Hintergrund »Mining«-Algorithmen für Kryptowährungen ausführt. Diese melden ihre Ergebnisse unbemerkt über jeden offenen Port, auf den sie zugreifen können, und bereichern dadurch ihre Schreiber. Ein perfides Vorgehen – schließlich werden weder Daten gestohlen noch der Datenschutz gefährdet oder böswillige Aktionen eingeleitet. Der einzige Effekt ist, dass CPU-Zyklen »verschwinden«. Bei einem Embedded-System, das eine Echtzeit-Reaktion aufweisen muss, kann das im schlimmsten Fall zu einem Leistungsausfall in einem kritischen Moment führen.

Realisiert wurde Cryptojacking bislang hauptsächlich über versteckten Code auf Websites. Es ist jedoch nicht schwer, sich ein Embedded-System vorzustellen, das auf einer Linux-Distribution basiert und versehentlich eine ungeschützte Internetverbindung hat, die gefunden und ausgenutzt wird. Auf ähnliche Weise lassen sich Systeme mit Internetverbindung als »Bots« übernehmen und für Angriffe Dritter nutzen.

Was tun?

Dass Sicherheit ein Problem ist, dürfte den Entwicklern von Embedded-Systemen mittlerweile bekannt sein. Weniger klar ist jedoch, was genau sie dagegen tun sollen. Der Software-Inhalt eines Embedded-Designs enthält häufig Code aus verschiedenen Quellen. Es wird Code speziell für das Projekt geschrieben, es werden aber auch Teile aus früheren Aufgaben wiederverwendet. Es kann Segmente geben, die von den Hardware-Anbietern eines Systems abgeleitet wurden, etwa IP wie Peripherietreiber für On-Chip-Funktionen. Es können auch Open-Source-Codeblöcke in ein Design importiert werden. Die­jenigen, die sich für eine gründliche Überprüfung der Integrität des eingebetteten Codes aussprechen, sind der Ansicht, dass zumindest alle Abschnitte der Software einer Anwendung in Quellform verfügbar sein sollten.

Die Desktop-Umgebung ist seit vielen Jahren ein »Schlachtfeld« und es hat sich ein Ökosystem entwickelt, das Sicherheitsbedrohungen entgegenwirkt. Das bekannteste Beispiel ist Windows und das fortlaufende Programm von Microsoft mit Updates und Patches. Der zentrale Punkt ist hier, dass Microsoft die Verantwortung für die kontinuierliche Robustheit seines Produkts übernimmt, auftretende Bedrohungen analysiert und die entsprechenden Patches bereitstellt. Im Embedded-Bereich existieren keine derartigen Support-Strukturen.

Da der Code in den meisten Designs von Embedded-Systemen in Form einer einzelnen ausführbaren Binärdatei vorliegt, trifft der Patch-Gedanke hier kaum zu. Ein vollständiges (Versions-)Update ist die einzige Möglichkeit. Für sie sind jedoch in den meisten Fällen Eingriffe des Benutzers erforderlich – in der Regel durch Laden einer neuen Flash-Konfiguration. Dadurch wird der Mechanismus dafür ebenfalls zu einem Aspekt des zu sichernden Designs. Das heißt, es sollte – zumindest – eine starke Log-in-Barriere geben, bevor das System eine authentifizierte Aktualisierung akzeptiert.

Ein Anbieter, der diesen Aspekt her­vorhebt, ist etwa STMicroelectronics. Das Unternehmen hat kürzlich bekannt gegeben, an einem Paket für Secure Firmware Upgrades zu arbeiten, das mit einer Reihe von Kodierungs- und Authentifizierungsschemata im gesamten Portfolio bereitgestellt werden soll (Bild 1).