FlexRay in Betrieb nehmen

Beispiel-Applikationen

In der Praxis finden sich Schwachstellen meist nicht in den kryptographischen Verfahren selbst, sondern in der Umsetzung auf realen Geräten. Dies zeigen z.B. die Erfahrungen, die im vergangenen Jahrzehnt bei Pay-TV-Systemen gemacht wurden. Bei Embedded-Systemen wie im Automotive-Bereich hat der Angreifer häufig das anzugreifende Gerät in der Hand und kann teilweise direkt die gespeicherten Schlüssel angreifen: über Betriebssystem-Schwachstellen, direkten Hardware-Zugriff, JTAG oder andere Ansatzpunkte. Gegen solche Angriffe hilft der Einsatz spezieller Security-Hardware, der allerdings auch mit zusätzlichen Kosten verbunden ist. Auch auf Standard-Hardware lässt sich die Sicherheit jedoch erhöhen, z.B., indem man Schlüssel im prozessorinternen Flash speichert. Bei einem größeren abzusichernden Datenumfang ist es möglich, diesen mit einem intern gespeicherten Schlüssel zu verschlüsseln und im externen Speicher abzulegen.

Ein sicherer Speicher allein gewährleistet aber immer noch keine absolute Sicherheit: Ist ein direkter Zugriff auf die Schlüssel nicht möglich, gibt es auch noch andere Angriffe. Vor allem im Hinblick auf Smartcards wurden Verfahren entwickelt, um auf Basis so genannter Seitenkanäle interne Parameter zu rekonstruieren. So kann man durch Messung des Stromverbrauchs oder der elektromagnetischen Abstrahlung während einer kryptographischen Berechnung z.B. Rückschlüsse auf den verwendeten Schlüssel ziehen. Die Kenntnisse solcher Angriffsmöglichkeiten sind von wesentlicher Bedeutung, wenn Kryptoalgorithmen auf einem Embedded-System sicher umgesetzt werden sollen.

Auf der beigefügten CD befinden sich mehrere Beispiel-Applikationen. Als einfachstes Beispiel dient das Projekt „Standalone Demo“. Diese Applikation initialisiert den FlexRay Communication Controller und definiert zwei Message-Objekte in dem statischen Segment, eines als Sendeobjekt und eines als Empfangsobjekt. Durch Umschalten des aktiven Projektes lassen sich unterschiedliche Versionen der Software für beide Knoten generieren, die jeweils die Sendeobjekte der Gegenstelle als Empfangsobjekt definieren. Zum Ausführen der „Standalone Demo“ empfiehlt es sich, die Software auf einem der Boards in den Flash-Speicher zu laden und auf dem anderen mit dem bequemer zu nutzenden Monitor-Debugger zu arbeiten, da das Projekt der Einfachheit halber auf eine ausführliche Fehlerbehandlung verzichtet und daher beide Teilnehmer etwa gleichzeitig gestartet werden sollten. Andernfalls verlässt der zuerst gestartete Teilnehmer nach einer Anzahl von Versuchen die zur Synchronisierung des FlexRay-Busses notwendige Coldstart-Phase und reagiert dann bereits nicht mehr, wenn die Software auf dem zweiten Board gestartet wird.

Umsetzung in die Praxis

Die Beschränkungen typischer Automotive-Hardware bezüglich Performance und Speicherressourcen sowie die Anforderungen an Echtzeit-Fähigkeit bzw. Unterbrechbarkeit der relativ rechenintensiven kryptographischen Routinen stellen bei der Umsetzung herausfordernde Einschränkungen dar. Zum Teil kann diesen Einschränkungen bereits durch die Auswahl geeigneter kryptographischer Verfahren begegnet werden. Zusätzlich sind aber auch noch Standardisierungsbestrebungen, wie in der „Hersteller-Initiative Software“ (HIS) oder im AUTOSAR-Konsortium, Effizienzbetrachtungen sowie natürlich Fragen der kryptographischen Sicherheit für die im Automobilbau relevanten Produktzyklen zu berücksichtigen.

Während symmetrische Kryptographie, also etwa Blockchiffren, Hash-Funktionen und Message Authentication Codes (MAC), bezüglich Performance und Langzeitsicherheit meist unproblematisch sind, ist die Auswahl bei asymmetrischen Verfahren und geeigneten Schlüssellängen deutlich komplexer. Hier lohnt es sich – je nach Anwendungsfall –, neben gängigen Lösungen wie RSA auch fortschrittlichere Verfahren, z.B. auf Basis elliptischer Kurven (ECC), zu betrachten.

Die „Standalone Demo“ ist in der mitgelieferten Version (CD Version 1.3) zunächst nicht lauffähig. Die Fehlersuche gibt einen guten Überblick über die Synchronisationsmechanismen von FlexRay und die Funktionsweise des ERAY-Controllers. Durch das Zeitverhalten der Gegenstelle nutzt es beim Debuggen kaum, das Programm schrittweise zu durchlaufen, hier sind die zahlreichen, frei verwendbaren Status-LEDs auf dem FlexRay-Tochter-Board mit etwas Debug-Code sehr nützlich. Es zeigt sich, dass von beiden Teilnehmern der Coldstart-Zustand unerwartet verlassen wurde, stattdessen liegt Zustand „Integration“ vor, damit kann keiner der beiden Teilnehmer mehr eine Synchronisation vorgeben. Mit der neueren Version von der nachgelieferten CD Version 1.4 (auch im Web verfügbar) kommunizieren beide Boards korrekt. Mit dem Oszilloskop lassen sich die übertragenen Botschaften erkennen. Die beim Übersetzen der Beispielapplikationen auftretenden Compiler-Warnungen können ignoriert werden.

Als weitere Beispielapplikationen liegt „GetCCVersion“ vor, das die Versionsnummer des ERAY Communication Controllers ermittelt (Bild 2). In den beiden gelieferten Systemen befinden sich unterschiedliche Versionen des ERAY Communication Controllers mit den Versionen 1.1 bzw. 1.0.1 und den entsprechenden Versions-IDs 20100 und 20004.

Neben der Auswahl ist vor allem die effiziente und dabei sichere Implementierung der kryptographischen Routinen von zentraler Bedeutung. Je nach vorgesehener Anwendung stehen dabei die erreichbare Performance oder der möglichst geringe Speicherbedarf im Vordergrund. Während z.B. bei externen Gateways im Fahrzeug-Bordnetz zur Kommunikation nach außen ein hoher Durchsatz im Vordergrund steht, müssen bei kryptographischen Routinen auf kleineren Steuergeräten vor allem die sehr knappen Speicherressourcen berücksichtigt werden. Sowohl durch Wahl geeigneter Parameter und Protokollvarianten als auch durch Codierungstechniken bei der Implementierung selbst können entweder die Laufzeit oder die Code-Größe erheblich optimiert werden.

ERAY Communication Controller

Der FlexRay Communication Controller kann durch Programmierung des FPGA aktualisiert werden, ein entsprechender Bitstream ist auf der CD Version 1.4 enthalten. Hierzu wird auf die Software Quartus II von Altera verwiesen. Die empfohlene Version 4.2 ließ sich nicht finden, daher wurde die aktuellere Version 5 von Quartus II verwendet.

Zur Verbindung wird ein JTAG-Adapter für den Parallelport verwendet. Die Software lässt sich problemlos installieren; nach Auswahl des Anschlusses findet man mittels der Funktion „Autodetect“ zwei Bausteine. Wie beschrieben, wird der Flashspeicher gewählt, aus dem der FPGA nach einem Reset die Konfiguration lädt. Beim Versuch, den Baustein neu zu programmieren, meldet Quartus bereits beim ersten Versuch einen Fehler beim „Blank Check“. Nach erneutem Versuch wird die FPGA-Konfiguration erfolgreich überschrieben. Beim Programmieren des zweiten Boards kommt es immer wieder zu Fehlern an verschiedenen Stellen beim „Blank Check“ und beim „Verify“. Erst nach Wechsel auf einen anderen Rechner funktioniert die Programmierung auf Anhieb.

Als einfache Testapplikation auf Basis der „Standalone Demo“, soll eine Taste eingelesen, in eine FlexRay-Message übertragen und auf der Gegenstelle durch eine LED ausgegeben werden. Die Boards enthalten eine freie Bedientaste auf dem CPU-Board, diese ist allerdings ohne Hardwaremodifikation nicht mit dem Monitor-Debugger nutzbar, da bei beiden Testboards eine Betätigung der freien Bedientaste häufig einen Puls auf den Eingang der benachbarten Stopp-Taste erzeugt, so dass der Debugger das Programm stoppt. Die vier Bedientasten auf dem ERAY-Board sind reserviert. Stattdessen wird einer der zahlreichen per Pfostenstecker erreichbaren Prozessorports verwendet. Zur Anzeige werden die auf dem FlexRay-Board über ein Customregister des ERAY-Controllers steuerbaren LEDs genutzt.

Zur Übertragung wird in beiden Teilprojekten ein neues Objekt im Message-Buffer als Sende- bzw. Empfangsobjekt definiert. Dazu muss der Header definiert werden, eine Adresse für den Datenteil im Message-RAM zugewiesen und für Sendeobjekte der Datenbereich mit Inhalt gefüllt werden. Zu beachten ist, dass die CRC-Prüfsumme des Message-Headers vom Hostcontroller vorgegeben werden muss; der ERAY-CC kann diese nicht selbst berechnen. Es stehen bis zu 64 Message-Buffer zur Verfügung. Zum Zugriff wird ein Satz von Kontrollregistern verwendet, der identisch für alle 64 Objekte ist. Die Adressierung der Objekte geschieht durch Schreiben eines Request für das gewünschte Objekt; in diesem Fall wird die Kontrollstruktur über einen Satz von Schattenregistern mit dem Objekt getauscht. Der Zugriff auf den Datenteil der Message-Objekte erfolgt in gleicher Weise.

Eine weitere Applikation auf der mitgelieferten CD ist das „CAN Gateway“. Dieses Projekt verwendet die Commstack-Bibliothek von DeComSys. Diese liegt dem FlexRay-Evaluation-Kit bei und muss vor dem Übersetzen in das Hauptverzeichnis des Projektes kopiert werden. Die Beispielapplikation empfängt Messages über das CAN-Interface des CPU-Boards und überträgt diese als statische FlexRay-Signale an das zweite Board, das die Botschaften wiederum über CAN versendet. Die notwendigen Einstellungen für die CAN-Kommunikation müssen aus den Quelldateien des Beispiels ermittelt werden.

Aus diesen Typen von Algorithmen lassen sich verschiedene andere herleiten:

• Message Authentication Codes (MAC) – eine kryptographische Checksumme, die bei Berechnung und Überprüfung einen Schlüssel erfordert – können sowohl auf Basis einer Hash-Funktion als auch auf Basis eines symmetrischen Verschlüsselungsalgorithmus realisiert werden.
• Digitale Signaturen lassen sich auf Basis asymmetrischer Verfahren realisieren, indem die zu signierenden Daten zunächst gehasht und der resultierende Hash-Wert dann mit einem privaten Schlüssel signiert wird. Den öffentlichen Schlüssel zur Verifikation kann man dann allgemein zugänglich machen.

Die Unterschiede zwischen symmetrischen und asymmetrischen Verfahren sind bei der Umsetzung sehr groß: Symmetrische Verfahren basieren auf relativ schnellen Operationen, während für asymmetrische Verfahren arithmetische Langzahl-Operationen notwendig sind, die zu relativ hohen Rechenzeiten führen. So erreicht man beispielsweise bei symmetrischer Verschlüsselung auf üblichen Embedded-Prozessoren einen Durchsatz von einigen Kilobyte pro Sekunde, während die Erstellung einer einzelnen digitalen RSA-Signatur mehrere Sekunden benötigt. Typische Verfahren sind in Tabelle 1 zusammengefasst. Mit diesen Verfahren lassen sich nun verschiedene Aufgaben erfüllen:

• Vertraulichkeit: Daten oder Nachrichten sollen nur von berechtigten Geräten bzw. Personen gelesen werden können.
• Integrität: Es muss feststellbar sein, ob Daten (unberechtigt) verändert wurden.
• Authentizität: Der Urheber von Daten muss eindeutig identifizierbar sein.
• Verbindlichkeit: Der Urheber von Daten soll nicht in der Lage sein zu bestreiten, diese Daten erzeugt zu haben (nur mit asymmetrischen digitalen Signaturen möglich).

1. FlexRay in Betrieb nehmen
2. Kryptographie – Voraussetzung für verlässliche Funktion
3. Autor
5. Beispiel-Applikationen
6. Was ist wirklich sicher?