Autoren: Florian Pramme, Jan-Phillip Foltz, Prof. Dr.-Ing. Gert Bikker, Ostfalia-Hochschule f\u00fcr angewandte Wissenschaften<\/p>\n
Dieser Beitrag stellt den durch das nieders\u00e4chsische Ministerium f\u00fcr Wissenschaft und Kultur gef\u00f6rderten Forschungsschwerpunkt „SecuRIn – Security Referenzmodell Industrie 4.0“ vor. Das Ziel dieses interdisziplin\u00e4ren Forschungsschwerpunkts ist es, Vorgehensmodelle zu entwickeln, die Unternehmen dabei unterst\u00fctzen, Anwendungen im Bereich Industrie 4.0 in Zukunft einfach sicher zu entwickeln und w\u00e4hrend des gesamten Lebenszyklus sicher zu betreiben. Der hier im Beitrag verwendete Anwendungsfall orientiert sich an der Digitalisierung von Fahrzeugen und den damit verbundenen Spannungsfeldern. Konkret sind Untersuchungen unternommen worden, aktuelle Automotive-Verschl\u00fcsselungschips hinsichtlich ihres Zeitverhaltens im Sicherheitslebenszyklus zu analysieren.<\/strong><\/p>\n Die Vernetzung von Autos mit dem Internet und untereinander wird schon seit l\u00e4ngerer Zeit diskutiert. Die Vorteile, die die M\u00f6glichkeit eines mit seiner Umgebung verbundenen Fahrzeugs bietet, sind offensichtlich. Software-Updates „Over-the-Air“<\/em>\u00a0w\u00fcrden eine immense Kosteneinsparung f\u00fcr die Automobilhersteller bedeuten. Weiter k\u00f6nnte das Fahren viel komfortabler und angenehmer gestaltet werden, wenn das Fahrzeug schon fr\u00fch mit der n\u00e4chsten Kreuzung kommuniziert und eine Gr\u00fcnphase einleitet oder hohe Verkehrsaufkommen und Gefahrenstellen durch intelligente Umleitung der Fahrzeuge entlastet werden. Doch wo T\u00fcren ge\u00f6ffnet werden, da treten auch gerne ungebetene G\u00e4ste ein.<\/p>\n Dass Angriffe auf Fahrzeugnetzwerke m\u00f6glich sind, wurde bereits mehrmals \u00f6ffentlichkeitswirksam demonstriert. Zu nennen ist ein Angriff auf den Jeep Cherokee im Jahr 2015, bei dem es zwei Sicherheitsforschern gelang, \u00fcber das Internet eine Sicherheitsl\u00fccke im Infotainment-System auszunutzen, um bei voller Fahrt die Kontrolle \u00fcber das Fahrzeug zu \u00fcbernehmen\u00a0[1]. Selbst bei Fahrzeugen ohne Internetanbindung ist es bereits mehrfach gelungen, die Kontrolle \u00fcber ein Fahrzeug entweder zu \u00fcbernehmen oder den Fahrbetrieb drastisch zu beeintr\u00e4chtigen. So schafften es die selben zwei IT Security Spezialisten, \u00fcber die bereits \u00fcber mehrere Jahre eingesetzte Diagnose-Schnittstelle OBD unter anderem in Bremsung und Lenkung eines Toyota Prius bei voller Fahrt einzugreifen\u00a0[2]. Dies zeigt, dass Security im Fahrzeug in der Vergangenheit keineswegs ausreichend Betrachtung gefunden hat.<\/p>\n Grunds\u00e4tzlich kann gesagt werden, dass sich das Ziel von Kryptografie f\u00fcr In-Vehicle Kommunikation eher auf\u00a0Integrit\u00e4t<\/em>,\u00a0Nachrichtenauthentisierung<\/em>\u00a0und\u00a0Authentizit\u00e4t<\/em>\u00a0konzentriert, weniger auf\u00a0Vertraulichkeit<\/em>. Der Inhalt dieser Nachrichten ist nicht zwingend sch\u00fctzenswert f\u00fcr den Betrieb des Fahrzeugs und des Bussystems. Beim Einsatz eines Kryptografieverfahrens innerhalb dieser Dom\u00e4ne ist es besonders wichtig, dass die Kommunikation nicht verz\u00f6gert wird.<\/p>\n Asymmetrische Verschl\u00fcsselungen\u00a0kommen f\u00fcr die In-Vehicle Kommunikation nicht in Frage, da die Hardwareanforderungen und stetig steigenden Schl\u00fcssell\u00e4ngen f\u00fcr diese Verfahren zu gro\u00df sind. Au\u00dferdem ist die asymmetrische Verschl\u00fcsselung\u00a0f\u00fcr die Broadcast\u00a0Nachrichten des CAN-Busses im Fahrzeug nicht geeignet. Deshalb sollte in der In-Vehicle Kommunikation vorrangig ein symmetrisches Verfahren f\u00fcr die Standardkommunikation genutzt werden. Die Authentisierung\u00a0der Nachrichten k\u00f6nnte man entweder durch Verschl\u00fcsselung mit der Zunahme von einer Nonce\u00a0in der Nachricht oder durch MACs realisieren. Unabh\u00e4ngig vom eingesetzten Verfahren ist die Verteilung der Schl\u00fcssel und die Anordnung der Steuerger\u00e4te\u00a0im Netzwerk wichtig. Separierte Teilnetze mit eigenen Schl\u00fcsseln und mit einem Supergateway, welches viele Security-Mechanismen wie\u00a0Firewalls<\/em>,\u00a0Intrusion Detection<\/em>,\u00a0Schl\u00fcsselerneuerung<\/em>\u00a0und\u00a0Steuerger\u00e4tsauthentifizierung<\/em>\u00a0implementiert, klingen vielversprechend. Auch Updates k\u00f6nnen so vorher von diesem zentralen Gateway\u00a0durch asymmetrische Verfahren verifiziert werden. Dadurch k\u00f6nnen die Steuerger\u00e4te\u00a0selbst komplett auf asymmetrische Verfahren verzichten. Au\u00dferdem w\u00e4re eine solche Topologie stark angelehnt an die bereits im Fahrzeug eingesetzte Topologie mit Teilnetzen und Gateways. Die Schl\u00fcssel der Teilnetze sollten regelm\u00e4\u00dfig erneuert werden, um es Angreifern zu erschweren, diese zu knacken.<\/p>\n Die bereits stark ausgelasteten Steuerger\u00e4te besitzen meist keine Ressourcen f\u00fcr die zus\u00e4tzliche Implementierung von Kryptografiealgorithmen. Au\u00dferdem sind diese oft sehr anspruchsvoll und brauchen eine hohe Rechenleistung, um in vorgeschriebenen Zeitfenstern die Aufgaben bearbeiten zu k\u00f6nnen. Aus diesem Grund ist es unausweichlich, den Steuerger\u00e4ten\u00a0zus\u00e4tzliche Hardware zur Verf\u00fcgung zu stellen, die f\u00fcr Kryptografie optimiert ist. Diese werden in Zukunft Standard bei Steuerger\u00e4ten\u00a0werden und ein Set von unterschiedlichen Kryptografiealgorithmen implementieren. Dass diese Hardwarebeschleunigungen eine signifikante Performanceverbesserung\u00a0und Entlastung des Hauptprozessors bieten k\u00f6nnen, zeigen die folgenden Messungen.<\/p>\n F\u00fcr den exemplarischen Vergleich eines in Frage kommenden Kryptografie-Hardwarechips mit einem normalen Steuerger\u00e4t bot sich das\u00a0Cyptrographic Acclerator and Assurance Module\u00a0<\/em>(CAAM) des i.MX6 von NXP an. Dieses unterst\u00fctzt verschiedenste Kryptografieverfahren, wodurch es die EVITA medium Anforderungen erf\u00fcllt [3]. Gemessen wird jeweils einmal auf der Haupt-CPU des i.MX6 und auf dem CAA-Module, welches \u00fcber die\u00a0cryptodev<\/em>\u00a0Library angesprochen wird. Die Messungen werden jeweils 5 Sekunden f\u00fcr Datenbl\u00f6cke der Gr\u00f6\u00dfe 16Byte* 2^x bis 65.536Byte durchgef\u00fchrt, und die Anzahl der fertig chiffrierten\/gehashten wird Bl\u00f6cke gez\u00e4hlt. Daraus wird anschlie\u00dfend ein Datendurchsatz\u00a0berechnet. Zus\u00e4tzlich wurden die Diagramme mit Messwerten der Escrypt GmbH f\u00fcr ihre Kryptobibliothek\u00a0CycurLIB<\/em>\u00a0[4] beigef\u00fcgt, um einen Vergleich zu realen Steuerger\u00e4ten zu haben. Dieses besitzt einen 32-Bit Cortex-M3@80MHz Prozessor<\/p>\n (s.\u00a0PDF<\/a>, Bild „Abb. 1 – AES CBC-Verschl\u00fcsselung mit 128 Bit Schl\u00fcssell\u00e4nge“)<\/p>\n Aus A sind die Messdaten f\u00fcr die AES CBC Verschl\u00fcsselung mit 128 Bit Schl\u00fcssell\u00e4nge zu entnehmen. Zu erkennen ist, dass die Softwarel\u00f6sung unabh\u00e4ngig von der Datenmenge einen relativ konstanten Datendurchsatz um 35 MB\/s aufweist. Die Hardwarel\u00f6sung hingegen hat Schwierigkeiten mit kleinen Datenmengen, wird mit gr\u00f6\u00dferen Datenmengen jedoch st\u00e4rker. Das Steuerger\u00e4t besitzt einen Datendurchsatz von ca. 0,76 MB\/s. Dadurch kann bereits ab 64 Byte die Hardwareunterst\u00fctzung einen signifikanten Geschwindigkeitsvorteil gegen\u00fcber der ECU vorweisen.<\/p>\n In Abb.\u00a01<\/strong>\u00a0(s.\u00a0PDF<\/a>) steht die CPU-Auslastung w\u00e4hrend der Messungen f\u00fcr die Schl\u00fcssell\u00e4ngen 128, 192 und 256 Bit im Vordergrund. Klar zu sehen ist, dass die CPU-Last\u00a0beim Testverfahren \u00fcber\u00a0cryptodev<\/em>(HW)\u00a0stark sinkt. Je gr\u00f6\u00dfer die Datenbl\u00f6cke werden, desto geringer wird auch die CPU-Last, da mehr Rechenleistung auf den Cryptochip ausgelagert wird. Dabei ist die Schl\u00fcssell\u00e4nge irrelevant f\u00fcr die CPU-Last. Die\u00a0OpenSSL<\/em>-Softwarel\u00f6sung fordert eine konstante Volllast des Prozessors, sodass diese bei dauerhaft 100% liegt. \u00dcberraschend ist allerdings die relativ hohe Auslastung bei kleinen Datenmengen. Dort ist bei der Hardwarel\u00f6sung 70% CPU-Auslastung zu beobachten. Vermutlich ist auch dies der Grund f\u00fcr die schlechten Messwerte bei kleinen Datenmengen bei der Hardware.<\/p>\n Abb.\u00a02<\/strong>\u00a0(s.\u00a0PDF<\/a>) zeigt die prozentuale Steigung der Zeit pro Paket. Konkret bedeutet dies, wenn ein Paket bestehend aus 16 Byte eine Millisekunde zum Verschl\u00fcsseln ben\u00f6tigt und ein weiteres Paket bestehend aus 32 Byte zwei Millisekunden, so ergibt sich eine Steigung von 100%. Die Softwarel\u00f6sung besitzt immer eine Steigung von circa 100%. Die Hardwarel\u00f6sung hingehen zeigt bis einem KB nur eine Steigung von ca. 10%. Also ist unabh\u00e4ngig von der Datenmenge die Verschl\u00fcsselungszeit nahezu gleich lang. Das ist besonders f\u00fcr Fahrzeugnetzwerke sehr wichtig, da diese strenge Echtzeitanforderungen besitzen.<\/p>\n Wenn man die erzielten Messergebnisse des CAA-Moduls direkt mit den Softwareperformance-Werten vergleicht, so sind diese Werte eher ern\u00fcchternd. Allerdings muss dabei beachtet werden, dass der vorliegende i.MX6\u00a0einen ARM Cortex A9 Quad Core Prozessor mit 1GHz Taktrate besitzt. Ein solcher Prozessor ist f\u00fcr momentan eingesetzte Steuerger\u00e4te\u00a0nicht \u00fcblich. Aus diesem Grund ist davon auszugehen, dass dieses CAA-Modul\u00a0in einem Automotive-Steuerger\u00e4t trotzdem eine Performanceverbesserung\u00a0bietet. Die Performance\u00a0im Vergleich zu g\u00e4ngigen Steuerger\u00e4ten\u00a0zeigt hier ein klareres Bild.<\/p>\n Was jedoch allgemein zu erkennen ist, ist dass die Performance\u00a0des Hardware-Chips\u00a0bei kleineren Blockgr\u00f6\u00dfen eher gering ist. Gleichzeitig ist an diesen Stellen die CPU-Last\u00a0selbst bei der Hardware ungew\u00f6hnlich hoch. Die Vermutung liegt nahe, dass der Flaschenhals hier die \u00dcbertragung des Verschl\u00fcsselungsauftrags von der CPU an das CAA-Modul\u00a0ist. Die besten Hardwareergebnisse sind immer an den Stellen mit der niedrigsten CPU-Belastung\u00a0zu finden. Wenn diese \u00dcbertragungsprobleme wegfallen, so k\u00f6nnte die Performance auch bei kleineren Bl\u00f6cken sicherlich enorm verbessert werden.<\/p>\n Besonders interessant ist, dass die Hardwareverschl\u00fcsselung f\u00fcr Datenbl\u00f6cke bis ~1KB keine gro\u00dfen zeitlichen Unterschiede in der Verschl\u00fcsselungszeit ben\u00f6tigt. Dies ist vor allem in Automotive-Umgebungen sehr wichtig, da zeitkritische Steuerungsdaten\u00a0eine bekannte Maximalverz\u00f6gerung haben m\u00fcssen und die Datenbl\u00f6cke nicht 1KB \u00fcbersteigen. Erst mit gr\u00f6\u00dferen Datenbl\u00f6cken steigt auch die prozentuale Steigerung des Hardwarechips st\u00e4rker an, erreicht aber fr\u00fchestens erst bei 65KB die 100% Marke, was einer Verdoppelung der ben\u00f6tigten Zeit im Vergleich zum vorherigen Block entspricht. Da sich die Blockgr\u00f6\u00dfen pro Schritt immer verdoppeln, die ben\u00f6tigte Zeit allerdings nicht, zeigt auch dies nochmal, dass der CAAM\u00a0Chip in diesen Messungen mit gr\u00f6\u00dferen Datenbl\u00f6cken besser zurechtkommt.<\/p>\n [1]\u00a0 A. Greenberg, \u201ewired.com,\u201c Juli 2015. [Online]. Florian Pramme<\/strong>\u00a0M.Sc. arbeitet seit 2011 als wissenschaftlicher Mitarbeiter innerhalb der\u00a0 Arbeitsgruppe von Prof. Dr.-Ing. Gert Bikker im Institut f\u00fcr verteilte Systeme der Ostfalia \u2013 Hochschule f\u00fcr angewandte Wissenschaften. Nach intensiver Besch\u00e4ftigung mit dem Thema Softwaretest und Simulation ist sein aktueller Forschungsschwerpunkt die virtuelle Absicherung von eingebetteten Systemen. Dar\u00fcber hinaus engagiert er sich innerhalb der Lehre und in der Entwicklung autonom fahrender Fahrzeuge.<\/p>\n Jan-Phillip Foltz<\/strong>\u00a0B.Sc. unterst\u00fctzt die Arbeitsgruppe seit 2017 im Bereich der Forschung von Sicherheitssystemen in Fahrzeugnetzwerken.<\/p>\n Beitrag als PDF downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema\u00a0Automotive\/ Embedded- und Echtzeit-Softwareentwicklung.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema Automotive \/Embedded- und Echtzeit-Softwareentwicklung steht\u00a0hier\u00a0<\/strong><\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nEinleitung<\/h2>\n
Stand der Technik<\/h2>\n
Kryptografieverfahren im KFZ-Netzwerk<\/h2>\n
Performancemessung der Kryptografieverfahren auf I.MX6<\/h2>\n
Literaturverzeichnis<\/h2>\n
\nAvailable: https:\/\/www.wired.com\/2015\/07\/hackers-remotely-kill-jeep-highway\/. [Zugriff am Oktober 2017].
\n[2]\u00a0 A. Greenberg, C. Miller und C. Valasek, \u201eHackers Reveal Nasty New Car Attacks,\u201c\u00a0Forbes Security,\u00a0<\/em>24 Juli 2013.
\n[3]\u00a0 EVITA, \u201eFinal EVITA Workshop on Security of Automotive On-Board Networks,\u201c November, 2011.
\n[4]\u00a0 W. Siebenpfeiffer, Vernetztes Automobil, Springer Verlag, 2014.<\/p>\nAutoren<\/h2>\n
\nAutomotive – unsere Trainings & Coachings<\/h2>\n
\nAutomotive – Fachwissen<\/h2>\n