Kryptographie im KFZ Verschlüsselung und System-Performance

Anbieter zum Thema

SonicWall Germany

Fujitsu Technology Solutions GmbH

SEPPmail - Deutschland GmbH

Ostfalia Hochschule für Angewandte Wissenschaften

Kryptographie gewinnt für Automotive Cyber Security an Bedeutung. Die Vernetzung von Autos mit dem Internet und untereinander, sowie deren Auswirkungen auf die Automotive Security werden schon seit längerer Zeit diskutiert. Welche Auswirkungen haben Verschlüsselungs­verfahren aber auf die Performance solcher sicherheitskritischen embedded Systeme?

Die Vorteile die die Möglichkeit eines mit seiner Umgebung verbundenen Fahrzeugs bietet sind offensichtlich. Software Updates „Over-the-Air“ würden eine immense Kosteneinsparung für die Automobilhersteller bedeuten. Weiter könnte das Fahren viel komfortabler und angenehmer gestaltet werden, wenn das Fahrzeug schon früh mit der nächsten Kreuzung kommuniziert und eine Grünphase einleitet oder hohe Verkehrsaufkommen und Gefahrenstellen durch intelligente Umleitung der Fahrzeuge entlastet werden. Doch wo Türen geöffnet werden, da treten auch gerne ungebetene Gäste ein.

Automotive Cyber Security: Stand der Technik

Das Angriffe auf Fahrzeugnetzwerke möglich sind wurde bereits mehrmals öffentlichkeitswirksam demonstriert. Weithin bekannt ist bereits der Angriff auf den Jeep Cherokee im Jahr 2015. Hierbei gelang es zwei Sicherheitsforschern, über das Internet eine Sicherheitslücke im Infotainment-System auszunutzen, um bei voller Fahrt die Kontrolle über das Fahrzeug zu übernehmen.

Selbst bei Fahrzeugen ohne Internetanbindung ist es bereits mehrfach gelungen die Kontrolle über ein Fahrzeug entweder zu übernehmen oder den Fahrbetrieb drastisch zu beeinträchtigen. So schafften es die selben zwei IT Security Spezialisten über die bereits über mehrere Jahre eingesetzte Diagnose Schnittstelle OBD unter anderem in Bremsung und Lenkung eines Toyota Prius bei voller Fahrt einzugreifen [1]. Dies zeigt, dass Security im Fahrzeug in der Vergangenheit keineswegs ausreichend Betrachtung gefunden hat.

Kryptografieverfahren im KFZ-Netzwerk

Grundsätzlich kann gesagt werden, dass das Ziel von Kryptografie für In-Vehicle Kommunikation sich eher auf Integrität, Nachrichtenauthentisierung und Authentizität konzentriert, weniger auf Vertraulichkeit. Der Inhalt dieser Nachrichten ist nicht zwingend schützenswert für den Betrieb des Fahrzeugs und des Bussystems. Beim Einsatz eines Kryptografieverfahrens innerhalb dieser Domäne ist es besonders wichtig, dass die Kommunikation nicht verzögert wird.

Asymmetrische Verschlüsselungen kommen für die In-Vehicle Kommunikation nicht in Frage, da die Hardwareanforderungen und stetig steigenden Schlüssellängen für diese Verfahren zu groß sind. Außerdem ist die asymmetrische Verschlüsselung für die Broadcast Nachrichten des CAN Busses im Fahrzeug nicht geeignet. Deshalb sollte in der In-Vehicle Kommunikation vorrangig ein symmetrisches Verfahren für die Standardkommunikation genutzt werden. Die Authentisierung der Nachrichten könnte man entweder durch Verschlüsselung mit der Zunahme von einer Nonce in der Nachricht oder durch MACs realisieren. Unabhängig des eingesetzten Verfahrens ist die Verteilung der Schlüssel und die Anordnung der Steuergeräte im Netzwerk wichtig. Separierte Teilnetze mit eigenen Schlüsseln und mit einem Supergateway, welches viele Security Mechanismen wie Firewalls, Intrusion Detection, Schlüsselerneuerung und Steuergerätsauthentifizierung implementiert, klingen vielversprechend. Auch Updates können so vorher von diesem zentralen Gateway durch asymmetrische Verfahren verifiziert werden. Dadurch können die Steuergeräte selbst komplett auf asymmetrische Verfahren verzichten. Außerdem wäre eine solche Topologie stark angelehnt an die bereits im Fahrzeug eingesetzte Topologie, mit Teilnetzen und Gateways. Die Schlüssel der Teilnetze sollten regelmäßig erneuert werden um es Angreifern zu erschweren diese zu knacken.

Die bereits stark ausgelasteten Steuergeräte besitzen meist keine Ressourcen für die zusätzliche Implementierung von Kryptografiealgorithmen. Außerdem sind diese oft sehr anspruchsvoll und brauchen eine hohe Rechenleistung um in vorgeschriebenen Zeitfenstern die Aufgaben bearbeiten zu können. Aus diesem Grund ist es unausweichlich zusätzliche Hardware den Steuergeräten zur Verfügung zu stellen, die für Kryptografie optimiert ist. Diese werden in Zukunft Standard bei Steuergeräten werden und ein Set von unterschiedlichen Kryptografiealgorithmen implementieren. Dass diese Hardwarebeschleunigungen eine signifikante Performanceverbesserung und Entlastung des Hauptprozessors bieten können, zeigen die folgenden Messungen.

Performancemessung der Kryptografieverfahren auf i.MX6

Für den exemplarischen Vergleich eines in Frage kommenden Kryptografie Hardwarechips mit einem normalen Steuergerät, bat sich das Cyptrographic Acclerator and Assurance Module (CAAM) des i.MX6 von NXP an. Dieses unterstützt verschiedenste Kryptografieverfahren, wodurch es die EVITA medium Anforderungen erfüllt [2]. Gemessen wird jeweils einmal auf der Haupt CPU des i.MX6 und auf dem CAA Module welches über die cryptodev Library angesprochen wird. Die Messungen werden jeweils 5 Sekunden für Datenblöcke der Größe 16 Byte* 2^x bis 65.536 Byte durchgeführt und die Anzahl der fertig chiffrierten/gehashten Blöcke gezählt. Daraus wird anschließend ein Datendurchsatz berechnet. Zusätzlich wurden die Diagramme mit Messwerte der Escrypt GmbH für ihre Kryptobibliothek CycurLIB [3] beigefügt, um einen Vergleich zu realen Steuergeräten zu haben. Dieses besitzt einen 32-Bit Cortex-M3@80MHz Prozessor.

Bildergalerie

Aus Bild 1 sind die Messdaten für die AES CBC Verschlüsselung mit 128 Bit Schlüssellänge zu entnehmen. Zu erkennen ist, dass die Softwarelösung unabhängig der Datenmenge einen relativ konstanten Datendurchsatz um 35 MB/s aufweist. Die Hardwarelösung hingegen hat Schwierigkeiten mit kleinen Datenmengen wird mit größeren Datenmengen jedoch stärker. Das Steuergerät besitzt einen Datendurchsatz von ca. 0,76 MB/s. Dadurch kann bereits ab 64 Byte die Hardwareunterstützung einen signifikaten Geschwindigkeitsvorteil gegenüber der ECU vorweisen.

In Bild 2 steht die CPU-Auslastung während der Messungen für die Schlüssellängen 128, 192 und 256 Bit im Vordergrund. Klar zu sehen ist, dass die CPU-Last beim Testverfahren über cryptodev(HW) stark sinkt. Umso größer die Datenblöcke werden, umso geringer wird auch die CPU-Last, da mehr Rechenleistung auf den Cryptochip ausgelagert wird. Dabei ist die Schlüssellänge irrelevant für die CPU-Last. Die OpenSSL - Software Lösung fordert eine konstante Volllast des Prozessors, sodass diese bei dauerhaft 100% liegt. Überraschend ist allerdings die relativ hohe Auslastung bei kleinen Datenmengen. Dort ist bei der Hardwarelösung 70% CPU Auslastung zu beobachten. Vermutlich ist auch dies der Grund für die schlechten Messwerte bei kleinen Datenmengen bei der Hardware.

Bild 3 zeigt die prozentuale Steigung der Zeit pro Paket. Konkret bedeutet dies, wenn ein Paket bestehend aus 16 Byte eine Millisekunde zum Verschlüsseln benötigt und ein weiteres Paket bestehend aus 32 Byte zwei Millisekunden so ergibt sich eine Steigung von 100%. Die Softwarelösung besitzt immer eine Steigung von circa 100%. Die Hardwarelösung hingehen zeigt bis einem KB nur eine Steigung von ca. 10%. Also ist unabhängig der Datenmenge die Verschlüsselungszeit nahezu gleich lang. Das ist besonders für Fahrzeugnetzwerke sehr wichtig, da diese strenge Echtzeitanforderungen besitzen.

Wenn man die erzielten Messergebnisse des CAA Moduls direkt mit den Softwareperformance-Werten vergleicht, so sind diese Werte eher ernüchternd. Allerdings muss dabei beachtet werden, dass der vorliegende i.MX6 einen ARM Cortex A9 Quad Core Prozessor mit 1GHz Taktrate besitzt. Ein solcher Prozessor ist für momentan eingesetzte Steuergeräte nicht üblich. Aus diesem Grund ist davon auszugehen, dass dieses CAA-Modul in einem Automotive Steuergerät trotzdem eine Performanceverbesserung bietet. Die Performance im Vergleich zu gängigen Steuergeräten zeigt hier ein klareres Bild.

Was jedoch allgemein zu erkennen ist, ist dass die Performance des Hardware-Chips bei kleineren Blockgrößen eher gering ist. Gleichzeitig ist an diesen Stellen die CPU-Last selbst bei der Hardware ungewöhnlich hoch. Die Vermutung liegt nahe, dass der Flaschenhals hier die Übertragung des Verschlüsselungsauftrags von der CPU an das CAA-Modul ist. Die besten Hardwareergebnisse sind immer an den Stellen mit der niedrigsten CPU-Belastung zu finden. Wenn diese Übertragungsprobleme wegfallen, so könnte die Performance auch bei kleineren Blöcken sicherlich enorm verbessert werden.

Besonders interessant ist, dass die Hardwareverschlüsselung für Datenblöcke bis ~1KB keine großen zeitlichen Unterschiede in der Verschlüsselungszeit benötigt. Dies ist vor allem in Automotive Umgebungen sehr wichtig, da zeitkritische Steuerungsdaten eine bekannte Maximalverzögerung haben müssen und die Datenblöcke nicht 1 KByte übersteigen. Erst mit größeren Datenblöcken steigt auch die prozentuale Steigerung des Hardwarechips stärker an, erreicht aber frühestens erst bei 65 KByte die 100% Marke, was einer Verdoppelung der benötigten Zeit im Vergleich zum vorherigen Block entspricht. Da die Blockgrößen sich pro Schritt immer verdoppeln, die benötigte Zeit allerdings nicht, zeigt auch dies nochmal, dass der CAAM Chip in diesen Messungen mit größeren Datenblöcken besser zurechtkommt.

Über diesen Beitrag

Dieser Beitrag stellt den durch das niedersächsische Ministerium für Wissenschaft und Kultur geförderten Forschungsschwerpunkt "SecuRIn - Security Referenzmodell Industrie 4.0" vor. Das Ziel dieses interdisziplinären Forschungsschwerpunkts ist es Vorgehensmodelle zu entwickeln, die Unternehmen dabei unterstützen, Anwendungen im Bereich Industrie 4.0 in Zukunft einfach sicher zu entwickeln und während des gesamten Lebenszyklus sicher zu betreiben. Der hier im Beitrag verwendete Anwendungsfall orientiert sich an der Digitalisierung von Fahrzeugen und die damit verbundenen Spannungsfelder. Konkret sind Untersuchungen unternommen worden, aktuelle Automotive-Verschlüsselungschips hinsichtlich ihres Zeitverhaltens im Sicherheitslebenszyklus zu analysieren.

API-Management für mehr Fahrzeugsicherheit in Connected Cars

Assistiertes & Autonomes Fahren: Worauf es bei der IT-Sicherheit wirklich ankommt

Die Autoren

* Florian Pramme M.Sc. arbeitet seit 2011 als wissenschaftlicher Mitarbeiter innerhalb der Arbeitsgruppe von *Prof. Dr.-Ing. Gert Bikker im Institut für verteilte Systeme der Ostfalia – Hochschule für angewandte Wissenschaften. Nach intensiver Beschäftigung mit dem Thema Softwaretest und Simulation ist sein aktueller Forschungsschwerpunkt die virtuelle Absicherung von eingebetteten Systemen. Darüber hinaus engagiert er sich innerhalb der Lehre und in der Entwicklung autonom fahrender Fahrzeuge.

* Jan-Phillip Foltz B.Sc. unterstützt die Arbeitsgruppe seit 2017 im Bereich der Forschung von Sicherheitssystemen in Fahrzeugnetzwerken.

Literaturhinweise

[1] A. Greenberg, C. Miller und C. Valasek, „Hackers Reveal Nasty New Car Attacks,“ Forbes Security, 24 Juli 2013.

[2] EVITA, „Final EVITA Workshop on Security of Automotive On-Board Networks,“ November, 2011.

[3] W. Siebenpfeiffer, Vernetztes Automobil, Springer Verlag, 2014.

Dieser Beitrag erschien zuerst auf dem Portal Embedded-Software-Engineering.de, einem Angebot von Elektronikpraxis. Verantwortlicher Redakteur: Sebastian Gerstl.

(ID:45285959)