Safety und Security von Embedded Systemen Sicherheitstrends für vernetzte Geräte

Getrieben durch »intelligente« M2M-Kommunikation, Multimedia-Fähigkeit, Internet-Anbindung und Finanztransaktionen mit erheblichem Wert, wird die Elektronikwelt immer raffinierter. Zugleich sind diese Funktionen aber vor Netzwerk-Attacken nicht gefeit und somit ein attraktives Ziel für Hacker. Neue Sicherheitseinrichtungen sind also erforderlich, deren Wirkungsweise Elektronikentwickler verstehen müssen.

Thema dieses ausführlichen, zweiteiligen Beitrags sind die Beschreibung wichtiger Sicherheitsanforderungen sowie praktische Anleitungen zu deren Umsetzung. Während der erste Teil unter anderem die Herausforderungen nennt und zuverlässige Hardware-Lösungen abdeckt, wird Teil 2 (in der kommenden Ausgabe der DESIGN&ELEKTRONIK) sichere Software, den Schutz gespeicherter Daten und eine sichere Netzwerkverbindung behandeln.

Zu den Herausforderungen für die Sicherheit vernetzter Geräte gehört zweifellos die steigende Komplexität. Eines der ersten elektronischen Systeme in einem amerikanischen Auto war der Bordcomputer im 1978er Cadillac Seville auf Basis eines 6802-Mikroprozessors von Motorola mit 128 Byte RAM und 2 KByte ROM. Der ausgedruckte Quellcode war nicht länger als ein paar Seiten.

Heute enthalten Fahrzeuge der unteren Klassen mindestens ein Dutzend, Autos der Oberklasse bis zu hundert Mikroprozessoren. Da Infotainment-Systeme meist auf anspruchsvollen Betriebssystemen wie Windows und Linux laufen, kann der Umfang der gesamten Software in einem Fahrzeug heute leicht 100 Millionen Codezeilen überschreiten. Diese Weiterentwicklung ist sicherlich zum Vorteil aller, wirft aber auch Sicherheitsfragen auf: Viele Probleme mit dem Verlust von Qualität und Sicherheit in der Elektronik entstehen, weil sich die zunehmende Komplexität nicht effizient genug verwalten lässt.

Bedrohung durch Attacken

Ein weiterer deutlicher Trend bei elektronischen Systemen ist deren zunehmende Anbindung an Netzwerke. Dadurch lassen sich die Systeme aus der Ferne verwalten beziehungsweise steuern und im Feld upgraden. Mit einer von General Motors (GM) im Jahr 2010 vorgestellten Funktion können Autobesitzer über ein Smartphone die Schlösser ihrer Fahrzeuge betätigen und den Motor starten.

Sollten Verbraucher nun besorgt über die Sicherheit bei dieser Art von Vernetzung sein? Nun - noch vor GMs Ankündigung legten Forscher einer Universität in einer Studie dar, wie sich solche kritischen Systeme in einem Fahrzeug (Bremsen, Motordrosselung, etc.) böswillig manipulieren lassen, indem der Angreifer Schwächen in der Fahrzeugelektronik ausnutzt.

Forscher demonstrieren heute sogar Attacken über Wide-Area-Networks, zum Beispiel über die Telematik-Verbindung. Handel, kritische Infrastrukturen und lebenswichtige Funktionen hängen immer stärker von elektronischen Geräten ab, wodurch diese attraktiv werden für gut gerüstete und entschlossene Angreifer. Und industrielle Steuerungssysteme finden sich in Kernreaktoren, Ölraffinerien und anderen kritischen Infrastrukturen, die ein großes Schadenspotenzial bieten.

So wurde der »Stuxnet«-Virus in Siemens-Prozessleitsysteme in kerntechnischen Anlagen eingeschleust und ist wahrscheinlich die erste direkt zur Attacke eines elektronischen Leitsystems entwickelte Schadsoftware. Sie demonstriert das unglaublich raffinierte Vorgehen moderner Angriffe auf die Sicherheit von Elek-tronik und beweist, dass hohe und verbesserte Sicherheitsaufwendungen beim Elektronikdesign erforderlich sind.

Eine weitere Beeinträchtigung der Sicherheit resultiert aus der Konsolidierung von Einzelprozessoren. Ein Beispiel sind auch hier die modernen Autos mit immer mehr Elektronik und enormen Herausforderungen für die Hersteller in Sachen Fertigungskosten, Platzbedarf und Markteinführungszeit. Die Reaktion darauf ist eine Trendumkehr, indem ursprünglich getrennte Funktionen wieder zusammengeführt werden, um letztendlich weniger elektronische Baugruppen zu erhalten.

Eine solche Konsolidierung erfordert entsprechende Systemarchitekturen, die sicherstellen, dass die Komponenten nicht auf unvorhersehbare Weise interagieren und ein mögliches Risiko darstellen. Ein Beispiel ist die Konsolidierung einer Infotainment-Einheit mit einer Rückfahrkamera und einem Fahrerassistenzsystem (ADAS - Advanced Driver Assistance System, Bild 1).

So kann das Rückfahrkamera-Modul auch die Audio- und Videofunktionen des Rechners in der Mittelkonsole nutzen, allerdings gilt das Modul als sicherheitsrelevante Funktion. Alle genannten Trends fordern ein Sicherheitsbewusstsein bei den Entwicklern sowie kritische Sicherheitstechniken, um diese Komplexität zu bewältigen und entsprechende Schutzfunktionen zu gewährleisten.

»Root of Trust«

Um das Vertrauen in die Sicherheit eines vernetzten Systems herzustellen, bedarf es eines »Vertrauensankers« (engl.: Root of Trust). Am Anfang steht ein Design, das dem Anwender die Gewissheit gibt, dass die getestete Firmware/Software immer läuft und während der Auslieferung oder im Betrieb nicht manipuliert wurde. Das Erstellen eines sicheren Ausgangszustands wird als »sicheres Booten« (Secure Boot) bezeichnet.

Um einen sicheren Ausgangszustand in elektronischen Systemen zu erreichen, muss Firmware in mehreren Stufen ausgeführt werden. Meist läuft auf der CPU zunächst ein kleiner »Boot-Loader« ab, der bei der Fertigung fest in das ROM programmiert wurde. Sicheres Booten hängt von Vertrauensfunktionen auf Hardwarebasis ab. So wird angenommen, dass der Inhalt des ROM nach der Fertigung nicht mehr verändert werden kann.

Der ROM-Loader lädt meist einen »Second Level Boot Loader« mit mehr Funktionen, der sich im integrierten Flash-Speicher befindet. Dieser Boot-Loader startet dann das primäre Betriebssystem, das die Anwendungen hostet. Bei der typischen sicheren Boot-Methode wird gewährleistet, dass jede Komponente in diesem Ablauf echt ist. Ist eine Verbindung unterbrochen, gilt auch der sichere Zustand als verletzt.

Der erste ROM-Loader muss über einen vorher fest einprogrammierten kryptographischen Schlüssel verfügen, um seinerseits die digitale Signatur des nächsten Boot-Loaders zu verifizieren. Diesen anfänglichen Verifikationsschlüssel muss die Hardware bereitstellen, er kann über eine einmal programmierbare Sicherung in das ROM integriert oder in einem lokalen »TPM« (Trusted Platform Module) abgelegt sein.

Weil der Signaturschlüssel prüft, ob die Komponenten in der zweiten Stufe des Boot-Ablaufs echt sind, muss die »Known good«-Signatur ebenfalls im hardware-geschützten Bereich gespeichert sein. Die Überprüfung der Komponenten auf zweiter Ebene deckt ihre ausführbaren Images sowie die »Known good«-Signatur und den Signaturschlüssel einer dritten Stufe ab - sofern vorhanden. Diese Verifikationskette kann beliebig lang sein.

In ausgeklügelten Systemen können überraschend lange Ketten oder sogar Bäume verifizierter Komponenten vorliegen, die zusammen die »Trusted Computing Base« (TCB) ausmachen. In der Computersicherheit bezieht sich der Begriff TCB auf die Teile eines Systems (Software und Hardware), die sicherheitskritisch sind und daher vertrauenswürdig sein müssen.

Bild 2 zeigt ein Beispiel einer sicheren Boot-Sequenz in drei Stufen. Sicheres Booten bietet Entwicklern die Gewissheit, dass das Produkt gegen Firmware-Manipulationsversuche geschützt ist. Dennoch kann ein Hacker eventuell böswillig eine Identität vortäuschen. So kann er zum Beispiel ein Smart Meter durch eine Einheit ersetzen, die genauso aussieht, aber heimlich private Verbrauchsdaten an eine Schad-Website sendet.

Selbst mit sicherem Booten muss sich die Anwendung dann zusätzlich vergewissern, dass ein Produkt in der Tat mit dem »Known good-TCB« betrieben wird. Wenn elektronische Systeme mit Management-Netzwerken verbunden sind, kann hierzu eine Bescheinigung aus der Ferne (Remote Attestation) erfolgen. Ein einfacher Ansatz ist für jedes elektronische System möglich: Das System kann einen sicheren Kanal mit IKE/IPsec oder SSL und öffentlicher Verschlüsselung im gegenseitigen Authentifizierungsmodus zu einem Beglaubigungs-Server im Netzwerk aufbauen.

Innerhalb dieser Protokolle kommt der private Schlüssel, der die Identität des Systems repräsentiert, zur Unterzeichnung von Daten zum Einsatz. Diese Daten authentifiziert daraufhin die Beglaubigungseinheit auf dem Server. Wichtig ist dabei, dass dieser private Schlüssel und die Client-Seite der Protokollsoftware für die sichere Verbindung in der TCB enthalten sind, die während des sicheren Boot-Vorgangs validiert wurde. Denn nur dann hat die Beglaubigungseinheit die Gewissheit, dass das System mit der erwarteten Firmware läuft.

Natürlich ist der Hardware-Vertrauensanker nutzlos, wenn fehlerhafte Software überprüft und gestartet wird. Als unverzichtbare Basis für die Elektronikentwickler ist also ein Software-Vertrauensanker nötig - ein zuverlässiges Betriebssystem, auf dem sich vertrauenswürdige Anwendungen entwickeln und betreiben lassen.

Wie so etwas aussieht, welche Arten von Betriebssystemen hier besondere Vorteile bieten, wie Virtualisierung hilft, auch weniger sichere Komponenten zu verwenden - all das wird der zweite Teil dieses Beitrags in der nächsten Ausgabe der DESIGN&ELEKTRONIK ebenso zeigen wie den Schutz gespeicherter Daten und den Aufbau einer sicheren Netzwerkverbindung.

Über den Autor:

David Kleidermacher ist Chief Technical Officer (CTO) bei Green Hills Software.