18ISO26262

IT-Sicherheit in Vernetzten Fahrzeugen

Herausforderungen

Vernetzte Fahrzeuge – was sind das für Vehikel? Es sind Fahrzeuge, die mit anderen technischen Systemen selbständig Verbindungen aufnehmen, um Informationen miteinander auszutauschen. Inzwischen gehören praktisch alle modernen Autos dazu. Und wenn sie das tun, dann wollen wir nicht im Straßengraben landen, wie jener Jeep-Cherokee, von dem im Sommer 2015 berichtet wurde, dass er von einem Hacker übernommen wurde, und dem Fahrer kein Mittel blieb, den Unfall zu verhindern. Und dieser Zwischenfall geschah nach Ankündigung des Hackers! Der Fahrer war also gewarnt.

Doch wie konnte es überhaupt dazu kommen? Hat der Fahrer etwas falsch gemacht? Sein Fehler mag es gewesen sein, überhaupt das Auto zu benutzen.

Wie passt nun IT-Sicherheit in diesen Zusammenhang? IT-Sicherheit ist gewissermaßen eine Vorbeugemaßnahme gegen den Gebrauch des Autos durch Dritte. Hier ist der vorgesehene Gebrauch – Beispiele sind Fernwartung oder Erfassung Fahrt-spezifischer Daten – von Fehlgebrauch oder Missbrauch durch Dritte zu unterscheiden.

Erinnern wir uns an den Jeep-Cherokee-Zwischenfall. Viele ähnliche Ereignisse hat es seit dem gegeben, die es bis in die Nachrichten geschafft haben. Im konkreten Fall war es dem Hacker gelungen, in das “Infotainment System” einzudringen, und von dort aus weitere Teilsysteme zu übernehmen, über die heutige Fahrzeuge verfügen. Mag sein, dass ungeeignete System-Designs diese Zwischenfälle ermöglichten. Aber: Es gibt eine systematische Erklärung für das leichte Leben der Hacker: Kurze Entwicklungszyklen – sowohl für die Fahrzeuge wie auch für Ihre elektronischen Systeme – zusammen mit beabsichtigter Typenvielfalt. Beide fordern die Endkontrolle der Hersteller heraus. Anstelle gründlicher Qualitätskontrollen verlassen sich Industrie und Organisationen auf Schnittstellenspezifikationen, die bindend sein sollen. Doch häufig sind Übermengen oder Untermengen von Inhalten und Formaten realisiert, auf die der andere Schnittstellenpartner nicht exakt abgestimmt ist.

Doch bevor wir tiefer in die Materie einsteigen, sollten wir ein paar Begriffe definieren. Nicht, um neue Worte zu erfinden, sondern um sicher zu gehen, dass wir eine gemeinsame Sprache sprechen und nicht aneinander vorbeireden.

IT-System       Dieser Begriff bezeichnet ein Konstrukt aus Hardware und Software, das eine Aufgabe erfüllen, eine Dienstleistung erbringen oder etwas Anderes – hoffentlich sinnvolles – tun soll. Meistens ist es nach seiner Hardware benannt. Jedes identifizierbare Steuergerät, das auf Software angewiesen ist, soll hier als IT-System angesehen werden.

Software        Software ist eine Bitfolge, die generiert wurde, um in einem IT-System spezifizierte Funktionen zu erfüllen. Sie besteht aus Instruktionen und Datenstrukturen, beide werden üblicherweise von Compilern erzeugt. Generell kann gesagt werden, dass Software der Qualitäts- und Konfigurationskontrolle von Herstellern und Nutzern unterliegt. Software ist das Gut, das ein IT-System das tun lässt, was es tun soll. Unterschiedliche Software kann dieselbe Hardware zu ganz unterschiedlich wirkenden IT-Systemen mutieren lassen.

Malware         Malware identifiziert eine Art von Software. Unabhängig von Ihrem Zweck soll Malware hier jegliche Software bezeichnen, die gegen die Absicht des Nutzers oder Betreibers eines IT-Systems installiert wurde. Falls also ein Nutzer eine Software so lädt, als sei sie Daten, dann ist das genauso Malware wie ein Virus, der von einem Hacker eingebracht wurde.

Safeware        Safeware bezeichnet die Software, die zum Nutzen des Betreibers erzeugt und installiert wurde. Safeware wird unter Beachtung der zugehörigen Dokumentation geladen und initialisiert. Sie unterliegt der Qualitäts- und Konfigurationskontrolle, ganz egal, ob und wo diese durchgeführt wird. Weil es in diesem Artikel schwerpunktmäßig um Hardware geht, wird davon ausgegangen, dass Safeware die höchsten Anforderungen hinsichtlich dieser Kontrollen erfüllt.

Zieldaten        Zieldaten sind diejenigen Daten, die ein betrachtetes IT-System entgegennehmen, bearbeiten oder zur Verfügung stellen soll. Als Beispiele können Daten von Sensoren oder Steuerdaten für Maschinen genannt werden. Zieldaten sind auch die Daten, die als Vehikel für das Einbringen von Malware dienen. Und wenn das steganografisch erfolgt, kann keine Firewall und kein Anti-Viren-Programm das erkennen oder gar etwas dagegen tun.

Nachdem diese Begriffe definiert sind, wollen wir ein konventionell gebautes IT-System hinsichtlich seiner sicherheitsrelevanten Komponenten betrachten:

Es besteht aus

• Prozessor,
• Festspeicher, z.B. Festplatte,
• Instruction-Bus,
• Operand-Bus und
• Arbeitsspeicher, häufig aus mehreren Chips bestehend.

Der entscheidende Punkt ist der Umstand, dass es weder beim Festspeicher noch beim Arbeitsspeicher eine physische Barriere gibt, die Safeware von Zieldaten trennt.

Wenden wir uns nun einer Hardware-Architektur zu, die dieses Manko nicht hat. Sie ist technisch nicht im Stande, Malware auszuführen. Es sind wieder nur die entscheidenden Komponenten erwähnt. Wir haben wieder

• Prozessor,
• Festspeicher, z.B. Festplatte,
• Instruction-Bus,
• Operand-Bus und – das ändert das Bild –
• Arbeitsspeicher für Safeware und
• Arbeitsspeicher für Zieldaten.
• Der Festspeicher ist außerdem jetzt ausschließlich für Zieldaten reserviert.
• Möglicherweise gibt es einen separaten Festspeicher für die Safeware.

Der optionale Festspeicher für Safeware darf getrennt von den IT-Systemen des Fahrzeugs sein, z.B. in einer Werkstatt oder einer anderen Service-Einrichtung.

Anforderungen an die Vernetzung

Nachdem wir die Hardware-Seite betrachtet haben, können wir uns nun den Herausforderungen der Kommunikation zuwenden, die in vernetzten, hochassistierten oder autonomen Fahrzeugen bestehen. Damit ist die Datenübertragung gemeint, die über externe Schnittstellen geführt wird, mit dem Ziel, große Datenmengen zwischen verschiedenen Fahrzeugen auszutauschen oder zwischen Fahrzeugen und z.B. stationären IT-Systemen.

Ein Problem dieser Kommunikation ist die Forderung, dass sie von den IT-Systemen selbständig initialisiert und aufrechterhalten werden soll, ohne Eingriffe des Fahrers oder einer anderen verantwortlichen Person. Selbst wenn wir von den häufig gestellten Fragen nach Verantwortung, Rechtfertigung und Haftung einmal absehen, muss sichergestellt sein, dass diese Kommunikation weder Fehlfunktionen verursacht, noch falsche Signale an die Steuergeräte sendet. – Oder zumindest solche Ereignisse auf ein Minimum reduziert.

In diesem Zusammenhang müssen wir fünf gefährliche Szenarien unterscheiden:

• • Das IT-System hat fehlerhafte Daten erhalten, die aber innerhalb des technisch zulässigen Wertebereiches liegen. Auf diesen Fall wird hier nicht näher eingegangen, denn auch Plausibilitätsprüfungen helfen nicht, Situationen zu meistern, die in der Nähe von Unfällen auftreten können, wo Objekte tatsächlich mit unerwarteten Kurs- und Fahrtwerten „manövrieren“, und denen trotzdem kollisionsfrei ausgewichen werden soll.
  • Seitenkanäle werden angegriffen. Hier handelt es sich noch nicht um einen Angriff im Sinne einer Attacke, sondern erst um die „Aufklärung“. Eine nachfolgende Attacke erfolgt dann möglicherweise per Malware, die eine zuvor aufgeklärte Schwachstelle ausnutzt.
  • Das System wird von mehr Kommunikationspartnern adressiert, als es in der verfügbaren Zeit abarbeiten kann. Diese „Denial of Service Attack“ genannten Angriffe werden mit der Absicht geführt, das attackierte System bei der zuverlässigen Ausführung seiner Aufgaben zu behindern. Obwohl auch diese Angriffe nicht zum eigentlichen Thema gehören, werde ich später kurz darauf zurückkommen.
  • Das IT-System ist mit steganografisch verborgener Malware infiziert. Diese Situation kann nicht automatisch erkannt werden, kann aber in konventionellen Systemen dazu führen, dass die verborgene Malware installiert und ausgeführt wird. Für die bevorzugte Hardware-Architektur stellt dieser Angriff nur einen anderen Schad-Software-Angriff dar.

• Das System wird von Schad-Software angegriffen: Das ist das Kernthema. Es wird die Notwendigkeit eines Technologiewandels bei digitalen, programmierbaren Geräten dargestellt, der deutlich hilft, den Grad der IT-Sicherheit signifikant zu erhöhen; und in dem er das bewirkt auch die Betriebssicherheit der Fahrzeuge deutlich verbessert, die mit solchen Geräten ausgerüstet sind.
  

 

IT-Security durch sichere Hardware-Architekturen

Wenn über herkömmliche Architekturen gesprochen wird, sagen IT-Sicherheitsexperten, dass es nur zwei Arten von Systemen gäbe: Diejenigen, in die Hacker bereits eingebrochen sind, und diejenigen, bei denen das noch nicht bemerkt worden ist.

Betrachtet man die Hardware-Architektur der IT-Systeme, die heute im Einsatz sind, so haben diese sich über Jahrzehnte hinweg kaum gewandelt. Sie sind prinzipiell aufgebaut, wie in Abbildung 1 dargestellt:

Verglichen mit Büro-Rechnern haben die IT-Systeme von Fahrzeugen einen weiteren Schwachpunkt, der dadurch bedingt ist, dass ihre Verbindungsaktivitäten nicht direkt überwacht werden. Und würden sie überwacht werden, dann blieben Fragen zu beantworten wie:

• Wie soll auf eine erkannte Unregelmäßigkeit reagiert werden?
  • Gerät abschalten? – Eine schlechte Wahl, es sei denn, auf die Funktion des Gerätes kann ohne Sicherheitseinbußen verzichtet werden.
  • Auf eine vorher fest gelegte Art reagieren? – Das ist nur dann eine gute Wahl, wenn Funktionalität und Reaktion des betroffenen Gerätes unbeeinflusst bleiben.
• Die angemessenste Reaktion in dieser Lage wäre – in Fahrzeugen wie in anderen verbundenen Systemen:
  • Nicht eingreifen!
  • Überhaupt nicht beachten!

Nicht nur, dass diese Reaktion Folgefragen vermeidet, bezüglich verschiedener Reaktionen auf verschiedene Situationen, sie bedarf auch keiner zusätzlichen Ressourcen: Weder im Voraus codierte Anweisungen, noch Prozessorlast auf Grund eines erkannten Angriffes. – Falls er denn erkannt wird!

Unglücklicherweise sind die meisten heute verwendeten Geräte nicht genügend ausgereift, um diese Wahl umsetzen zu können. Seit dem Arpanet – Vorläufer des Internet seit 1969 – war Software das Mittel, mit dem alle kommunikationsrelevanten Differenzen der damals sehr verschiedenen proprietären Hardware-Systeme überbrückt wurden. Das ist seit dem so geblieben. Sehr wenig Augenmerk wurde auf die Hardware als Mittel zur Lösung gelegt.

Das führte zur gegenwärtigen Situation: Wir benutzen nach wie von Hardware-Strukturen aus jener vergangenen Zeit; Hardware-Strukturen, die nicht dafür entworfen worden waren, Systeme funktionell miteinander zu verbinden.

Diese Architektur ist zwar alt geworden, aber nicht reif – jedenfalls nicht reif genug, um den Herausforderungen vernetzter IT-Systeme gewappnet zu sein. Doch unübersehbare Mengen von Software sind inzwischen in nahezu jeder Programmiersprache geschrieben worden, alle für diese alte Hardware-Architektur. Häufig sind es die Investitionskosten, die verhindern, dass in Hardware investiert wird, die den aktuellen Herausforderungen vernetzter Systeme besser gewachsen ist; sie sind der oberflächliche Vorwand, am Alten festzuhalten, an der alten Hardware wie an der alten Software. Aber neue, moderne Hardware-Architekturen benötigen nicht wirklich neue Software: Mittlerweile sind praktisch alle codierten Software-Algorithmen unabhängig von der Hardware, auf der sie ausgeführt werden sollen.

An dieser Stelle möchte ich darauf hinweisen, dass es wahrscheinlich nicht ausreichend sein wird, ein einzelnes sicheres Gerät zu integrieren, das die Aufgabe hat, das Eindringen von Schad-Software in ein IT-System zu verhindern. Wie früher schon erwähnt, braucht dieses Gerät nicht im Stande zu sein, Schad-Software zu erkennen – und wird es wohl auch nie sein. Außerdem ist das Erkennen steganografisch verborgener Schad-Software so gut wie unmöglich. Deshalb kann ein sicheres Erkennen und Unschädlichmachen von Schad-Software nicht erwartet werden. Im Umkehrschluss heißt das: Jedes Gerät muss für sich selbst sicher sein!

Lösungsansätze

Was also muss getan werden, um die Anzahl der auf Cyber-Risiken beruhenden Zwischenfälle unserer IT-Systeme zu reduzieren? Das Programmieren oder Anpassen von diesbezüglichen Software-Funktionen hat sich weithin als fragwürdige und unsichere Abhilfe erwiesen. Es wird Aktivitäten erfordern, die von manchen Leuten als disruptiv angesehen werden.

Der entscheidende Schritt, der getan werden muss, ist dieser: Innerhalb der IT-Systeme müssen die Daten, die bearbeitet werden sollen, komplett von allen Daten getrennt werden, die Teil der Safeware-Ausstattung sind.

Ein Handwerker wäre überrascht, wenn er diese Forderung hörte: Er und seine Kollegen haben bereits seit Generationen Werkzeuge und Werkstücke getrennt aufbewahrt – doch Computer-Fachleute packen beides – auch heute noch! – ins selbe Regal, sprich: speichern beides in den gleichen Speicher; einige von ihnen bestehen sogar auf die gegenseitige Austauschbarkeit. Also lautet die Forderung 1:

Safeware und Zieldaten verschiedenen, voneinander unabhängigen Speichereinheiten zuweisen!

Solche Architekturen sind während dieses Jahrzehnts entwickelt und patentiert worden, sie unterscheiden selbst innerhalb der Safeware unterschiedliche Datenkategorien. Eines der resultierenden IT-Systeme sieht – grob dargestellt – aus, wie in Abbildung 2 gezeigt:

Diese Darstellung wäre schon ausreichend, um eingebettet IT-Systeme im einsatzfähigen Zustand zu beschreiben.

Aber leider sind IT-Systeme nicht statisch! Von Zeit zu Zeit kommt eine Nachricht und überrascht die Nutzer-Gemeinde mit irgendeinem neuen Software-Update. Aber wann ist der Zeitpunkt gekommen, diesen zu installieren? Im Allgemeinen ist der Nutzer nicht ausreichend darüber informiert, wann System-Updates durchzuführen sind. Und wie ist das bei autonom fahrenden Fahrzeugen? Die haben nicht einmal einen identifizierbaren Nutzer! Darüber hinaus stellt so ein Software-Hersteller mit Updates nur für „sein“ IT-System bereit. Aber es gibt zahlreiche IT-Systeme verschiedener Hersteller in vernetzten Fahrzeugen, und die sind nicht etwa voneinander isoliert, sondern sie sind funktionell voneinander abhängig! Daraus lässt sich ableiten, wie Forderung 2 aussehen könnte:

Alle anstehenden Software-Updates sind in einer einzigen Maßnahme kontrolliert und koordiniert durchzuführen!

Dieser Schritt mag nicht sofort einsichtig sein: Kontrollierte und koordinierte Updates sind leicht zu rechtfertigen, wenn Schnittstellen betroffen sind: Jeder Fachmann erkennt die Notwendigkeit, alle von der Schnittstelle betroffenen Systeme gleichzeitig aufzudatieren. Würde man das nicht tun, dann wären nach dem Update diese Systeme nicht mehr in der Lage, miteinander zu kommunizieren. Diese Erklärung gilt auch für die Aufdatierung in einer einzigen Maßnahme: Man kann nicht erwarten, dass ein integriertes IT-System sicher funktioniert, wenn die einzelnen Komponenten nicht funktionell auf dem gleichen Stand sind und die korrekte Zusammenarbeit der Komponenten nicht geprüft wurde.

Software-Updates brauchen ihre Zeit, denn es gibt einige Aktivitäten, die durchgeführt werden müssen: Die alte Software deaktivieren, die neue Software laden, installieren und initialisieren. Wenn nun ein System mit Software-Updates beschäftigt ist, was machen dann die anderen? Sie machen dem Fahrer das Leben zur Hölle! – Falls er denn fahren sollte. Während der Aufdatierung kann das betrachtete System die ihm zugedachten Aufgaben nicht erfüllen – zumindest nicht für eine beträchtliche Zeitspanne. Die anderen Systeme werden das als Fehler erkennen und durch Warnungen oder Alarme versuchen, des Fahrers Aufmerksamkeit zu wecken. Aber diese arme Person kann nichts ausrichten! Er hat keine Möglichkeit, die Aufdatierung anzuhalten, abzubrechen, zu verzögern oder zeitlich zu verschieben! Ganz zu schweigen davon, dass er vermutlich obendrein das nötige Wissen nicht besitzt, dürfte er damit beschäftigt sein, das Fahrzeug unter seine eigene Kontrolle zu bringen! Und wie sieht das bei autonomen Fahrzeugen aus? Da gibt es nicht einmal einen Fahrer, der sich um die Warnungen kümmern könnte! Das leitet direkt zu Forderung 3:

Updates nur dann durchführen, wenn das Fahrzeug an keiner aktiven Rolle teilnimmt!

Das mag soweit vernünftig klingen – aber es gilt auch zu bedenken, dass mancher Fahrer an der Technik und dem Verhalten seines Fahrzeugs gar nichts ändern will! Vielleicht hat er gerade die Gewöhnungsphase für sein neues Fahrzeug beendet, und möchte da nicht noch einmal durch, oder zumindest nicht zu diesem Zeitpunkt. Und wieder kommt die Frage auf, ob der Fahrer oder Halter sein Tun oder Unterlassen richtig bewerten kann. An dieser Stelle sei ihm geraten, sich an Experten zu wenden, z.B. in Fachwerkstätten. Wie auch nach der Diesel-Abgasaffäre. Es gibt noch einen weiteren Grund, sich mit Software-Updates an Werkstätten oder ähnliche Dienstleister zu wenden: Nur diese dürften nach erfolgten Updates das Wissen und die Einrichtungen haben, die Integrität und das Zusammenwirken aller IT-Systeme des Fahrzeugs prüfen zu können. Zumindest dürften im Allgemeinen weder Fahrer noch Halter im Stande sein, solche Prüfungen durchführen zu können. Daraus ergibt dann auch schon Forderung 4:

Einrichtungen und Verfahren für sichere Software-Updates schaffen!

Werkstätten und ähnliche autorisierte Dienstleister – die unter Umständen erst noch eingerichtet werden müssten – sind mit solchen Software-Updates zu betrauen. Das bietet auch weitere Vorteile: Die IT-Systeme der Fahrzeuge können ohne eigene Vorrichtungen zum Laden von Software gebaut werden. Das spart nicht nur Herstellungskosten, sondern auch andere Ressourcen, wie Energie und Kühlung: Nicht vorhandene Fähigkeiten brauchen keine Energie und produzieren keine Wärme. Die fehlende Update-Funktion bei den Fahrzeug-IT-Systemen verhindert auch deren missbräuchliche Nutzung durch Widersacher mit ihren kriminellen Absichten.

Doch wie sollen mit den Software-Updates umgegangen werden? Es sind Dutzende von IT-Systeme in solch ein Fahrzeug integriert! Und die stammen obendrein in der Regel von verschiedenen Herstellern! Wird es permanent Aufforderungen hageln, Software-Updates zu installieren? Zwei- oder dreimal die Woche in die Werkstatt fahren dafür? In diesem Zusammenhang kommen schwer fassbare Dinge ins Spiel: Software-Qualität, Konfigurationskontrolle, Systemintegrität.

Ohne Zweifel verdienen die IT-Systeme von Fahrzeugen die höchstmöglichen Stufen dieser Attribute. Die Systemintegratoren werden dafür verantwortlich sein, diese Qualitäten zu gewährleisten, denn sie beeinflusst unmittelbar sämtliche Sicherheitsaspekte. Keine leichte Aufgabe! In den meisten Fällen werden die Fahrzeughersteller die juristischen Personen sein, die hierfür verantwortlich sind. Das kann neben der schon früher erwähnten notwendigen Infrastruktur zum Laden von Updates ein weiterer Grund für Software-Update in Werkstätten sein – nicht unbedingt in Marken-gebundenen.

Das “Wie“ lässt eine Reihe von Alternativen, die an dieser Stelle nicht diskutiert werden sollen. Erstens sind sie von nachgeordneter Bedeutung, und zweitens kann dieses Feld getrost dem Wettbewerb der Marktteilnehmer überlassen bleiben. Die wichtige Lehre, die hier zu ziehen ist, ist diese: Wenn Software-Updates Werkstätten überlassen bleiben, kann am ehesten gewährleistet werden, dass sie nicht während einer Fahrt vorgenommen werden.

Eine weitere Sache kann bei der vorstehenden Diskussion über Software-Updates direkt erkannt werden: So genannte Over-the-Air-Updates sind bei den IT-Systemen von Fahrzeugen weder notwendig, noch sind sie willkommen. Tatsächlich sind sie sogar gefährlich, weil sie System-Ressourcen – insbesondere Zeit – beanspruchen, was zu den schon erwähnten Folgen führen kann. Darüber hinaus spielen noch funktechnische Aspekte eine Rolle, von denen hier stellvertretend nur zwei genannt werden sollen: Interferenzen durch (Mehrfach-) Reflexionen der Signale und Abschattung der Empfangsantennen durch Berge, dichte Wälder oder Tunnel. Doch Over-the-Air-Updates können durchaus das Mittel der Wahl für die Hersteller der IT-Systeme sein! Allerdings nicht für die IT-Systeme der Fahrzeuge unmittelbar, sondern für die der Werkstätten, die auf diese Weise als Zwischenspeicher für solche Updates dienen, bis dann die Fahrzeuge eintreffen, um ihre Updates abzuholen. Vielleicht bietet sich hier für interessierte Werkstätten oder Dienstleister ein neues Geschäftsmodell an? Auf diese Weise hat dann letztendlich der Fahrer oder Halter doch noch das Heft in der Hand, wenn es um den Zeitpunkt der Aufdatierung geht.

Hier sei noch einmal darauf hingewiesen, dass Software-Updates ein Sicherheitsfaktor sind: Laienhaft oder durch Nicht-Fachleute unvollständig durchgeführte Updates gefährden Fahrzeug, Verkehr und Verkehrsteilnehmer. Außerdem ist eine gut dokumentierte Software-Pflege ein Mittel, das Fahrern und Haltern zum Vorteil gereichen kann, wenn es einmal darum gehen sollte, rechtliche Aspekte wie Verantwortung, Haftung oder dergleichen klären zu müssen. Wohl dem Fahrer oder Halter, der dann nachweisen kann, dass er seinen Verpflichtungen nachgekommen ist.

 

Verifikation der Eigenschaften sicherer Hardware-Architekturen

Nachdem die Forderungen vorgestellt wurden, kommt jetzt zwangsläufig die nächste Fragestellung: Welche Mittel und Verfahren stehen denn zur Verfügung, um die Sicherheitsattribute der IT-Hardware zu bewerten?

Hier soll gleich zu den entsprechenden Verfahren übergegangen werden, wohl wissend, dass vorher die Industrie die erforderlichen Dokumente wie Testpläne, Testspezifikationen, Testprozeduren und Testprotokolle erstellt haben wird.

Attribut 1: Unabhängige Speicherbereiche für Safeware und Zieldaten

Zugegeben, das ist nicht leicht zu überprüfen, aber es geht. Erste Hinweise lassen sich im Datenblatt des IT-Systems finden: Wenn dort keine separaten Speicherbereiche ausgewiesen sind, dann werden auch keine realisiert worden sein, und es ist kein sicheres Produkt. Ende der Prüfung. Ergebnis: Durchgefallen. Doch selbst wenn unabhängige Speicherbereiche ausgewiesen sind, muss sicherstellt werden, dass sie wie gefordert genutzt werden. Es wäre nicht das erste Mal, dass eine technische Neuheit durch unsachgemäße Anwendung ihren Zweck verfehlt hätte. Dafür werden muss auf Prüfprotokolle zurückgegriffen werden, in denen festgehalten worden ist, dass keine Bitfolgen von einem Speicherbereich in den anderen übertragen werden können. Das können Fachleute mit entsprechendem Aufwand in einer Test-Umgebung mit einem Debug-Tool verifizieren.

Attribut 2: Unvermögen, Malware auszuführen

Dieses Attribut lässt sich am praktischsten ebenfalls mit einem Debug-Tool nachweisen. Dafür sind drei Maßnahmen durchzuführen: 1.: Software in den Zieldatenspeicher einbringen. 2. Mit dem Debug-Tool alle erforderlichen Schritte durchführen, um diese Software auszuführen. Das Resultat sollte eine Fehlermeldung des Systems sein. 3. Überprüfen, ob die Fehlermeldung dem entspricht, was bei korrekter Implementation zu erwarten ist. Das ist notwendig um festzustellen, dass keine ungewollte Reaktion stattgefunden hat, wie z.B. Übertragung der Software in eine Sandbox. Wenn die Fehlermeldung korrekt ist, besteht im hohen Maße Sicherheit, dass die geprüfte Hardware tatsächlich nicht im Stande ist, Malware auszuführen.

Attribut 3: Abhängigkeit von externen Geräten zwecks Aktualisierung der Software

Auch dieses Attribut ist schwer zu beweisen. Allein die Tatsache, dass mit dem externen Gerät Software geladen werden kann, schließt nicht aus, dass es eine verborgene Funktion gibt, mit der Software-Laden eben doch möglich ist. Für diesen Nachweis müsste der Schaltplan des Gerätes zu Rate gezogen werden – oder ein freundlicher Hacker gefragt werden, ob er dieses Attribut verifizieren kann.

Für alle Attribute darf angenommen werden, dass im Laufe der Zeit praktikable und verifizierbare Methoden geschaffen werden, um sie nachzuweisen; sei es auf Grund werbewirksamer Überlegungen oder in der Folge von Vorgaben der Gesetzgebung.

Denial-of-Service-Attacken

Wie versprochen, wird zum Ende dieses Artikels auf dieses Thema noch einmal kurz eingegangen. Diese Angriffe beruhen darauf, dass eine Vielzahl von Systemen, die mit der gleichen Malware infiziert sind, gleichzeitig eine Lawine von Nachrichten an einen bestimmten Adressaten schickt. Die hier vorgestellten Hardware-Architekturen lassen das nicht mit sich machen: Die notwendige Malware kann schlicht und einfach nicht aktiviert werden. Statistisch betrachtet kann daraus Folgendes abgeleitet werden: Je mehr sich solche Malware-sicheren Hardware-Architekturen durchsetzen, umso weniger Systeme können sich an Denial-of-Service-Attacken beteiligen, und umso geringer werden deren Auswirkungen auf die übrigen gefährdeten Systeme sein.

Alle Argumente sprechen also für sichere Hardware-Architekturen – nicht nur für die IT-Systeme in Fahrzeugen, sondern überall dort, wo IT-Systeme miteinander kommunizieren.

Oktober 2017