Eine Frage der Safety oder der Security \u2013 oder von beidem?<\/p>\n
Autor*innen: Stefan Kriso, J\u00fcrgen Klarmann, Claudia Loderhose, Franziska Wiemer, Carsten Gebauer, Simon Burton, Robert Bosch GmbH; Markus Ihle, ETAS GmbH<\/p>\n
F\u00fcr ein sicheres automatisiertes Bewegen im Stra\u00dfenverkehr ist eine Umwelterfassung durch die Fahrzeugsensorik notwendig. Eine bestimmte Klasse von Gef\u00e4hrdungen ist heute nicht ausreichend adressiert – die\u00a0„Environmental Hacks“ im Sinne von Umweltmanipulationen. Zum Beispiel soll ein Stoppschild sicher erkannt werden. Eine relativ geringe vom menschlichen Auge nicht unbedingt als solche erkennbare Manipulation eines Verkehrszeichens kann eine Fehlklassifikation zur Folge haben, welche wiederum eine Gef\u00e4hrdung von Personen nach sich ziehen kann. Daher muss das System robust gegen solche Manipulationen sein. \u00c4hnliche Effekte k\u00f6nnen aber auch durch Verschmutzung des Verkehrszeichens auftreten. Daher muss man dies auch bei der Safety-Betrachtung der Nominalfunktion ber\u00fccksichtigen. Die Frage ist, wie man das Thema\u00a0„Environmental Hacks“ behandelt, da es sowohl Security (Manipulation) als auch Safety (Auswirkung) betrifft. Der Beitrag zeigt anhand von Beispielen, wie diese Frage beantwortet werden kann. Sicherheit im Sinne von Safety hat verschiedene „Feindbilder“, die durch unterschiedliche Methoden und Ma\u00dfnahmen adressiert werden.<\/p>\n Siehe Bild 1 (PDF<\/a>): „Feindbilder“ der Automotive Safety (Auswahl)<\/p>\n Systematische Fehler und zuf\u00e4llige Hardware-Fehler, die zu einem fehlerhaften Verhalten des Systems f\u00fchren k\u00f6nnen, werden durch die „Funktionale Sicherheit“ adressiert, die entsprechenden Methoden und Ma\u00dfnahmen sind in der ISO 26262 beschrieben. F\u00fcr die Sicherheit der Sollfunktion (SOTIF \u2013 Safety of the Intended Functionality) ist derzeit ein Standard in Arbeit, die ISO 21448. Hier wird die Frage adressiert, wie beispielsweise ein sicheres System gestaltet werden kann unter Ber\u00fccksichtigung physikalischer Unzul\u00e4nglichkeiten der Sensorik. Auch bewusste Manipulationen des Systems k\u00f6nnen Einfluss auf die Safety haben. Dies ist durch Ma\u00dfnahmen der Cybersecurity zu adressieren; hierf\u00fcr ist ebenfalls ein Standard in Vorbereitung (ISO\/SAE 21434).<\/p>\n Dar\u00fcber hinaus gibt es ein weiteres „Feindbild“, die Environmental Hacks, die wir anhand von drei Beispielen einf\u00fchren wollen:<\/p>\n Die Manipulation von Verkehrszeichen mag f\u00fcr den menschlichen Betrachter noch als solche erkennbar sein und das manipulierte Zeichen in seiner urspr\u00fcnglichen Intention f\u00fcr den Fahrzeugf\u00fchrer noch als solche erkennbar sein, so muss dies beim automatisierten Fahren nicht zwangsl\u00e4ufig auch gegeben sein. Bereits eine kleine aber gezielte Manipulation kann bei Bilderkennungsalgorithmen zu Fehlklassifikationen f\u00fchren ([3]), was dazu f\u00fchrt, dass das Verkehrszeichen vom System „\u00fcbersehen“ werden.<\/p>\n In [4] konnte sogar eine Manipulation demonstriert werden, in der ein System ein manipuliertes Stopp-Schild als ein Tempolimit-Schild fehlinterpretiert hat.<\/p>\n Siehe Bild 2 (PDF<\/a>): Beispiel f\u00fcr ein manipuliertes Verkehrszeichen [1]<\/p>\n Als ein weiteres Beispiel von Environmental Hacks k\u00f6nnen die Laser-Attacken angesehen werden, die gelegentlich auch in der Presse Erw\u00e4hnung finden ([5]). W\u00e4hrend dort meist \u00fcber Attacken auf menschliche Fahrer berichtet wird, haben derartige Attacken auch Auswirkungen auf die Sensorik und k\u00f6nnen letztendlich zum Ausfall oder zu einem Fehlverhalten f\u00fchren.<\/p>\n Dieser Angriff f\u00fchrt somit zu einem „Denial of Service“ und l\u00e4sst sich daher in die Kategorie der DoS-Attacke einordnen, auch wenn die St\u00f6rungsquelle au\u00dferhalb des Systems liegt.<\/p>\n Jammen und Spoofen von GNSS-Signalen (Global Navigation Satellite System) stellen weitere Manipulationen der Umwelt dar. Beim Jammen wird das Empfangen von GNSS-Signalen durch einen St\u00f6rsender verhindert. GNSS-Spoofing dagegen bezeichnet das Senden gef\u00e4lschter GNSS-Dignale. Diese sind von der Sensorik alleine nicht als F\u00e4lschungen erkennbar, da sie in sich valide sind.<\/p>\n GNSS-Jamming und -Spoofing k\u00f6nnen bewusst eingesetzt werden, um das Fahrzeugverhalten zu beeinflussen. Es gibt aber auch Szenarien, in denen GNSS-Jamming oder -Spoofing gegen andere Ziele gerichtet sind und das Fahrzeug nur versehentlich in den Einflussbereich von gest\u00f6rten oder gef\u00e4lschten Signalen ger\u00e4t.<\/p>\n In [13] wird von einem Fall berichtet, in dem ein LKW-Fahrer einen GPS-Jammer verwendet, um den im Fahrzeug eingebauten GPS-Tracker zu st\u00f6ren und damit seinen Aufenthaltsort vor seinem Vorgesetzten zu verbergen. Auf einem nahegelegenen Flughafen kommt es dadurch versehentlich zu St\u00f6rungen eines GPS-basierten Flugzeugleitsystems. Diese Auswirkungen lassen sich auf Fahrzeuge mit GPS-basierten Funktionen \u00fcbertragen.<\/p>\n [14] beschreibt eine GPS-Spoofing-Attacke, die Fahrzeuge mit GPS-basierten Funktionen unbeabsichtigt in Mitleidenschaft ziehen kann. Mit Hilfe eines Software Defined Radio werden gef\u00e4lschte GPS-Signale erzeugt, die der App „Pokemon Go“ einen falschen Aufenthaltsort des Spielers vorgaukeln. Dadurch kann der Spieler von zuhause aus spielen, ohne spazierengehen zu m\u00fcssen.<\/p>\n Die Anwendungsf\u00e4lle von GNSS-Spoofing sind vielf\u00e4ltig. Mit derselben Vorgehensweise lassen sich z.B. ortsgebundene Services unerlaubt aktivieren oder GPS-basierte Mautsysteme \u00fcberlisten. [12] verzeichnet eine Zunahme von GNSS-Jamming und Spoofing. Daher ist es wichtig, sie im Kontext von GNSS-basierten Fahrzeugfunktionalit\u00e4ten zu betrachten und zu analysieren.<\/p>\n Relevanz von Environmental Hacks f\u00fcr die Safety<\/strong><\/p>\n Wie aus den Beispielen deutlich wird, k\u00f6nnen Environmental Hacks Einfluss auf die Safety, die Verf\u00fcgbarkeit und die Performance des Produkts haben. F\u00fcr die Safety w\u00e4re ein Environmental Hack ein weiteres zu ber\u00fccksichtigendes „Fehlerbild“ (Bild 1, (PDF<\/a>).<\/p>\n Die Bereiche Verf\u00fcgbarkeit und Performance bei Environmental Hacks zielen nicht mehr auf die Safety des Produkts, sondern mehr in Richtung Benutzerakzeptanz: Die in unserem Beispiel relevante Fragen w\u00e4ren hierbei, ob es ein Benutzer akzeptieren w\u00fcrde, wenn ein selbstfahrendes Fahrzeug \u00f6fter unvermittelt anh\u00e4lt oder falsch abbiegt bzw. ob er es noch f\u00fcr vertretbar hielte, wenn sich ein automatisiertes Fahrzeug von einem Laser-Pointer zum Preis von 10 Euro au\u00dfer Kraft setzen lie\u00dfe.<\/p>\n Die Feindbilder der Funktionalen Sicherheit sind systematische Fehler und zuf\u00e4llige Hardware-Fehler. Zur Vermeidung systematischer Fehler werden Anforderungen an den Entwicklungsprozess („Safety Lifecycle“), zur Beherrschung zuf\u00e4lliger Hardware-Fehler und verbleibender systematischer Fehler (deren Vermeidung grunds\u00e4tzlich nicht vollst\u00e4ndig sichergestellt werden kann) Anforderungen an die technische Umsetzung im Produkt (z.B. Redundanzen, Monitoring, Diagnosen) gestellt.<\/p>\n Verlassen wir nun die Fehlerdbilder der Funktionalen Sicherheit, n\u00e4mlich die systematischen Fehler und zuf\u00e4lligen Hardware-Fehler, und schauen uns ein weiteres Feindbild an: den bewussten Angriff auf das Fahrzeug bzw. seine E\/E-Systeme. Zun\u00e4chst gilt festzustellen, dass wir uns mit diesem Feindbild au\u00dferhalb der Funktionalen Sicherheit und damit au\u00dferhalb des Anwendungsbereichs der ISO 26262 befinden. Trotzdem kann auch dieses Feindbild zu einem Safety-kritischen Verhalten f\u00fchren und daher prinzipiell Safety-relevant sein [8]. Dieses Feindbild wird adressiert durch die Ma\u00dfnahmen der Cybersecurity, die momentan in der ISO\/SAE 21434 „Cybersecurity Engineering“ standardisiert werden.<\/p>\n Siehe Bild 3 (PDF<\/a>): Prinzipielle Vorgehensweisen bei Safety und Security<\/p>\n Cybersecurity setzt als typische Gegenma\u00dfnahme oft Kryptographie ein, dies scheint hier im Falle der Environmental Hacks allerdings untauglich zu sein: Mit kryptographischen Ma\u00dfnahmen wird der Weg vom Input zum Output einer digitalen Funktion verschl\u00fcsselt bzw. authentifiziert. Die Manipulation bei den Environmental Hacks finden aber schon im Vorfeld (vor dem Input) statt, daher ist diese Absicherungsma\u00dfnahme untauglich. In einem einzelnen Eingangskanal kann nicht beurteilt werden, ob der Input valide ist oder nicht.<\/p>\n Somit l\u00e4sst sich schlussfolgern, dass die Environmental Hacks weder von der Safety-Analyse erfasst werden, weil sie nicht dem typischen Fehlerbild entsprechen, noch von der Security-Analyse, da dort der Blickwinkel meist nur das digitale System selbst und nicht auch dessen Umgebung ist.<\/p>\n Typische Safety-Ma\u00dfnahmen wie zum Beispiel Redundanz, Diversit\u00e4t und Plausibilisierungen k\u00f6nnten zwar durchaus erfolgsversprechen sein, allerdings kommen sie dort nicht zum Einsatz, wenn sie in der Safety-Analyse nicht als solche abgeleitet werden.<\/p>\n Bei n\u00e4herer Betrachtung der Anforderungen an den Entwicklungsprozess stellt man viele \u00c4hnlichkeiten der Safety- und Security-Aktivit\u00e4ten fest [8]:<\/p>\n Siehe Bild 4 (PDF<\/a>): \u00c4hnlichkeiten der Safety- und Security-Prozesse<\/p>\n Bez\u00fcglich der Environmental Hacks f\u00e4llt man jedoch sowohl bei blo\u00dfer Anwendung des Safety- als auch des Security-Prozesses durch das Raster, da keiner von beiden dieses Feindbild ausreichend adressiert. Somit f\u00fchrt uns dies zu einem erweiterten prozessualen L\u00f6sungsansatz:<\/p>\n Siehe Bild 5 (PDF<\/a>): Prozessualer Ansatz zur Behandlung von Environmental Hacks<\/p>\n Bei der \u00dcbergabe von Anforderungen an die Dom\u00e4ne der Funktionalen Sicherheit gilt zu beachten, dass zur Bewertung des Safety-Risikos nicht der ASIL gem\u00e4\u00df ISO 26262 herangezogen werden kann, da dieser implizit eine statistische Unabh\u00e4ngigkeit zwischen Fehlerauftreten und Fahrsituation voraussetzt [11], was bei einem Environmental Hack nicht unbedingt gegeben ist. Zur Bewertung des Safety-Risikos einer Manipulation von au\u00dfen ist daher ein anderes Kriterium notwendig, was momentan Gegenstand der Diskussion in den Safety- und Security-Communities ist [10].<\/p>\n Die urspr\u00fcngliche Form der Fragestellung zur Erkennung von Verkehrsschilder, auch wenn diese Modifizierungen aufweisen, ist in der Produktentwicklung bereits adressiert. Auch ohne bewusste Manipulation kann heute nicht davon ausgegangen werden, dass z.B. ein Stoppschild nur in Reinform auftritt und sich ohne jegliche Abweichung zu einem Referenzschild in der realen Umgebung befindet. Es muss stattdessen davon ausgegangen werden, dass zum Beispiel das Schild im Winter von Schneeflocken bedeckt oder durch Verschmutzung nur eingeschr\u00e4nkt erkennbar sein k\u00f6nnte. Weiter kann erwartet werden, dass ein System im assistierten oder automatisierten Fahren bei geringf\u00fcgigen Modifizierungen immer noch in der Lage ist, das Schild als solches zu erkennen und korrekt zu klassifizieren.<\/p>\n L\u00f6sungsans\u00e4tze f\u00fcr dieses Problemfeld werden in der SOTIF-Dom\u00e4ne erarbeitet. Die Erweiterung des Fokus von Schneeflocken und Schmutzpartikeln hin zu Klebestreifen oder Abdeckungen erwirkt die Erweiterung dieses Themas um bewusste Umweltmanipulationen und identifiziert somit die SOTIF als die Zieldom\u00e4ne f\u00fcr die Environmental Hacks.<\/p>\n Witterungsbedingte Abweichungen werden in der Bilderkennung ber\u00fccksichtigt und sind schon jetzt Bestandteil der Anlernphase eines „Deep Neural Networks“. Ein Ansatz zur Erweiterung der Probleml\u00f6sung um Environmental Hacks ist, auch solche manipulierten Objekte gezielt in das Deep Learning einzubringen, um so die Algorithmen diesbez\u00fcglich zu sensibilisieren und die Robustheit zu verbessern.<\/p>\n Es sind aber auch Gegenma\u00dfnahmen, die bereits im SOTIF-Umfeld zur Anwendung kommen, f\u00fcr diese Angriffsklasse adaptierbar: So sind zus\u00e4tzliche Validierungsma\u00dfnahmen \u00fcber den Kontext eine vielversprechende Gegenma\u00dfnahme. Es w\u00e4re beispielsweise nicht plausibel, wenn ein Stoppschild an einem kreuzungslosen Feldweg im Wald aufgestellt w\u00e4re, oder ein Tempo-60 Schild direkt an einer Verkehrskreuzung erscheinen w\u00fcrde.<\/p>\n Eine weitere wirkungsvolle Gegenma\u00dfnahme, die ebenfalls im SOTIF-Kontext ihre Anwendung findet, w\u00e4re beispielsweise die Etablierung einer zus\u00e4tzlichen Infrastruktur (Verkehrsschilder senden diversit\u00e4re Sensorsignale aus) oder ein Abgleich der erfassten Verkehrsschilder mit Karteninformationen.<\/p>\n Die Safety-Relevanz einer Blendung durch Laser-Pointer ist zum Beispiel aus der Luftfahrt hinl\u00e4nglich bekannt und wird auch entsprechend geahndet ([5]). Hierbei stand bisher insbesondere die Blendung von Personen im Fokus. Vorstellbar ist jedoch auch eine Blendung von Sensoren, so dass diese bei der Erfassung der Fahrzeugumgebung eingeschr\u00e4nkt sind.<\/p>\n Prinzipiell sollte dieses Fehlerbild in einer \u00e4hnlichen Art und Weise bereits im SOTIF-Umfeld betrachtet werden, da auch nat\u00fcrliche Quellen f\u00fcr Blendungen vorstellbar sind, zum Beispiel eine tiefstehende Sonnenscheibe. Auch dies darf nicht zu einem ungew\u00fcnschten, safety-kritischen Verhalten des Fahrzeugs f\u00fchren. Daher bietet sich an, die Fragestellung einer Blendung durch Laser-Pointer an die SOTIF-Dom\u00e4ne zu geben, da dort Ma\u00dfnahmen zur generellen Vermeidung bzw. Beherrschung dieses Fehlerbildes erwartet werden k\u00f6nnen, wenn man die dort getroffenen Betrachtungen auf die Frequenzbereiche der Laser-Pointer erweitert.<\/p>\n Als L\u00f6sungsm\u00f6glichkeiten sind beispielsweise redundante Sensorik, das Aufrechterhalten einer Mindestfunktionalit\u00e4t oder die \u00dcbergabe der Fahraufgabe an den Fahrer vorstellbar.<\/p>\n Auf technischer Ebene sind Ma\u00dfnahmen gegen die Auswirkungen von GNSS-Jamming und -Spoofing verf\u00fcgbar. Auf Fahrzeugebene hat GNSS-Jamming eine \u00e4hnliche Wirkung wie der Ausfall des GNSS-Sensors. Szenario dieser Art sind Teil der Safety-Betrachtung und k\u00f6nnen durch Safety-Ma\u00dfnahmen abgemildert werden, wie z.B. das Ausweichen auf einen redundanten Kanal zur Positionsbestimmung oder die Degradierung des Fahrzeugs in einen Zustand, der keine GNSS-Daten ben\u00f6tigt.<\/p>\n Die Auswirkungen von GNSS-Spoofing sind schwerer abzuwenden, da der GNSS-Sensor gef\u00e4lschte GNSS-Daten nicht von echten unterscheiden kann. Es gibt jedoch Ma\u00dfnahmen, mit denen das System „merken“ kann, dass eine Unregelm\u00e4\u00dfigkeit vorliegt. Ein pl\u00f6tzlicher Versatz in den empfangenen Positionsdaten um eine gr\u00f6\u00dfere Distanz kann mittels kontinuierlicher Plausibilit\u00e4tspr\u00fcfung der empfangenen Positionsdaten bemerkt werden. Ein schleichender Versatz f\u00e4llt beim Abgleich mit redundanten Positionsdaten, z.B. Kartendaten, auf.<\/p>\n Auf Prozessebene ist es dagegen schwierig, GNSS-Jamming und -Spoofing einzuordnen. Es ist weder Gegenstand der Functional Safety, da keine systematischen Fehler oder zuf\u00e4lligen Hardwarefehler urs\u00e4chlich sind. Noch sind derartige Angriffe ein Thema f\u00fcr SOTIF, weil sie nicht auf Unzul\u00e4nglichkeiten der Sensorik an sich basieren. Aktuell wird die Behandlung von GNSS-Jamming und -Spoofing nicht vollst\u00e4ndig von der Security abgedeckt, da im Rahmen der Risiko- und Bedrohungsanalyse nur (absichtliche) Angriffe auf das Fahrzeug oder einzelne Komponenten betrachtet werden. Der Kollateralschaden, der durch GNSS-Jamming oder \u2013Spoofing mit anderer Zielsetzung entstehen kann, bleibt au\u00dfen vor. Es muss daher eine Zieldom\u00e4ne identifiziert werden, die ggf.\u00a0 ihren Betrachtungsumfang und m\u00f6glicherweise ihre Methoden erweitern muss, um derartige Angriffe zu analysieren und geeignete Gegenma\u00dfnahmen abzuleiten.<\/p>\n Environmental Hacks k\u00f6nnen signifikanten Einfluss auf das Fahrzeugverhalten und seine Sicherheit (sowohl i.S.v. Safety als auch Security) haben. Dies ist durch die bisherigen Disziplinen (Bild 1. (PDF<\/a>) nicht vollst\u00e4ndig adressiert, da es sich um eine dom\u00e4nen\u00fcbergreifende Fragestellung handelt. Die Identifikation der betroffenen Fehlerbilder kann im Rahmen einer Security-Betrachtung erfolgen, danach erfolgt die \u00dcbergabe an die jeweils betroffenen Safety-Zieldom\u00e4nen. Hierzu sollte die bestehende Risiko- und Bedrohungsanalyse der Security entsprechend um die Environmental Hacks erweitert werden. Als Zieldom\u00e4ne f\u00fcr die Safety-Betrachtung wird sich oftmals die SOTIF (Safety of the Intended Functionality) anbieten, da hier die gr\u00f6\u00dften Synergien zu erwarten sind, es sind aber auch andere Safety-Zieldom\u00e4nen denkbar.<\/p>\n [1]\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0https:\/\/upload.wikimedia.org\/wikipedia\/commons\/4\/41\/Stop_eating_animals_sign.jpg<\/a><\/p>\n [2]\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Autonome Autos: Unsaubere Verkehrszeichen komplett falsch erkannt,\u00a0www.winfuture.de\/news,99034.html<\/a>\u00a0(abgerufen am 24.07.2018)<\/p>\n [3]\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Robust Physical-World Attacks on Deep Learning Models, [4]\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0https<\/a>:\/\/<\/a>www.youtube.com\/watch?time_continue=2&v=1mJMPqi2bSQ<\/a> [5]\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Haftstrafe f\u00fcr Laser-Blendung, [6]\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Anschlag mit Laserpointer: Busfahrer am Auge verletzt [7]\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Black Hat Europe: It\u2019s easy and costs only $60 to hack self-driving car sensors, [8]\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Security im Kontext der Funktionssicherheit: Wie Safety und Security zusammenh\u00e4ngen, Embedded Software Engineering Kongress 2015, Sindelfingen<\/p>\n [9]\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 ISO\/IEC 15408: \u201cThe Common Criteria for Information Technology Security Evaluation\u201c<\/p>\n [10]\u00a0\u00a0\u00a0\u00a0 Benjamin Glas, Carsten Gebauer, Jochen H\u00e4nger, Andreas Heyl, J\u00fcrgen Klarmann, Stefan Kriso, Priyamvadha Vembar, Philipp W\u00f6rz: \u201eAutomotive Safety and Security Integration Challenges\u201c, Automotive Safety and Security 2015, Stuttgart-Feuerbach<\/p>\n [11]\u00a0\u00a0\u00a0\u00a0 Stefan Kriso, Markus Ihle: \u201cAutomotive Security im Kontext der Funktionalen Sicherheit\u201c, Forum Safety & Security, M\u00fcnchen, 06.\u201307. Juli 2016<\/p>\n [12]\u00a0\u00a0\u00a0\u00a0 GPS unter Beschuss: Jamming und Spoofing nehmen zu [13]\u00a0\u00a0\u00a0\u00a0 Truck driver has GPS jammer, accidentally jams Newark airport,\u00a0 [14]\u00a0\u00a0\u00a0\u00a0 We Declare The Grandmaster Of Pokemon Go GPS Cheats Dipl.-Phys. Stefan Kriso<\/strong>\u00a0trat nach dem Studium der Physik 1995 in die Robert Bosch GmbH ein. In verschiedenen Positionen besch\u00e4ftigte er sich mit Fragestellungen der Hard- und Softwareentwicklung. Von 2005 bis 2011 leitete er in der zentralen Forschung und Vorausentwicklung ein Projekt, das einerseits die Bosch-Interessenvertretung in den nationalen und internationalen Normungsgremien zur ISO 26262, andererseits die Koordination der konzernweiten Einf\u00fchrung der ISO 26262 zur Aufgabe hatte. Seit 2011 leitet er bei Bosch das „Center of Competence Functional Safety“. Seit 2005 ist er nebenberuflich Dozent f\u00fcr Physik an der Dualen Hochschule Baden W\u00fcrttemberg, Stuttgart.<\/p>\n Kontakt: stefan.kriso@de.bosch.com<\/p>\n Dr. J\u00fcrgen Klarmann<\/strong>\u00a0studierte Informatik an der Universit\u00e4t Stuttgart und schloss sein Studium 1995 mit dem Diplom ab. Von 1995 bis 2002 war er als Wissenschaftlicher Angestellter an der Universit\u00e4t Stuttgart t\u00e4tig, an der er auch zum Dr. rer. nat. promovierte. Seit 2002 arbeitet er in der Robert Bosch GmbH in unterschiedlichen Funktionen im Unternehmensbereich Mobility Solutions. Seit 2008 ist er verst\u00e4rkt in die Functional Safety und die ISO 26262 involviert. Von 2013 bis 2015 war in der der ETAS GmbH als Senior Consultant f\u00fcr Safety, Security und Embedded Systems t\u00e4tig. Seit 2016 arbeitet er im Gesch\u00e4ftsbereich Chassis Systems Controls im dortigen „CC Center of Competence Security“.<\/p>\n Kontakt: juergen.klarmann@de.bosch.com<\/p>\n Dr. Claudia Loderhose<\/strong>\u00a0ist Diplom-Mathematikerin und promovierte Informatikerin. Seit 2017 arbeitet sie bei der Robert Bosch GmbH im Gesch\u00e4ftsbereich Chassis Systems Controls. Ihre Themenschwerpunkte sind Methoden zur Risiko- und Bedrohungsanalyse, die Einbindung von Securityaspekten in den Produktentwicklungsprozess sowie das Zusammenspiel zwischen Safety und Security.<\/p>\n Kontakt: claudia.loderhose@de.bosch.com<\/p>\n Franziska Wiemer<\/strong>\u00a0hat an der Ruhr-Universit\u00e4t Bochum IT-Sicherheit und Informationssicherheit (B.Sc und M.Sc) studiert und ist 2017 in die Robert Bosch GmbH eingetreten. Seitdem besch\u00e4ftigt sie sich mit Themen der IT-Sicherheit (Security) innerhalb von Fahrzeugen. Sie arbeitet unteranderem an der Entwicklung von Prozessen zur Integration von Security in Steuerger\u00e4ten \u2013\u00a0 dabei spielt aktuell auch das Zusammenspiel zwischen Safety und Security eine gro\u00dfe Rolle. Ein weiterer Schwerpunkt ihrer Arbeit ist der Datenschutz innerhalb von Chassis-Steuerger\u00e4ten, sowohl w\u00e4hrend der Entwicklung, als auch bei Datenr\u00fcckfluss im sp\u00e4teren Serienbetrieb.<\/p>\n Kontakt: franziska.wiemer@de.bosch.com<\/p>\n Dipl.-Phys. Carsten Gebauer<\/strong>\u00a0trat 2000 nach Abschluss seines Studiums der Bosch Gruppe bei. Sein Themenschwerpunkt ist seit 2004 die Safety. Er ist Mitglied der nationalen und internationalen Arbeitsgruppen, die mit der Erstellung der ISO 26262 und der ISO (PAS) 21448 beauftragt sind und arbeitet seit 2014 im „Bosch Center of Competence Functional Safety“.<\/p>\n Kontakt: carsten.gebauer@de.bosch.com<\/p>\n Dr. Simon Burton<\/strong>\u00a0studierte Informatik an der Universtiy of York, an welcher er auch zum Thema Verifikation und Validierung von sicherheitsrelevanten Systemen promovierte. Dr. Burton ist seit \u00fcber 20 Jahren in verschiedenen sicherheitsrelevanten Industrien t\u00e4tig gewesen. Er hat unter anderem Forschungs- und Entwicklungs\u00adprojekte bei gro\u00dfen OEMs sowie auch Beratungs-, Dienstleistungs- und Produktorganisationen geleitet. Zurzeit hat er die Rolle des Chief Experts bei Robert Bosch GmbH inne, in welcher er die Forschungs\u00adstrategie in den Bereichen funktionale Sicherheit, Security, Zuverl\u00e4ssigkeit und Verf\u00fcgbarkeit von Software-intensiven Systemen koordiniert.<\/p>\n Kontakt: simon.burton@de.bosch.com<\/p>\n Markus Ihle<\/strong>\u00a0studierte an der Universit\u00e4t Karlsruhe Elektrotechnik und schloss 1999 mit dem Diplom ab. Seit 2003 ist er in verschiedenen Bereichen und Funktionen des Bosch-Konzerns t\u00e4tig. Er war unter anderem an der Forschung und Entwicklung von Halbleiter\u00adbau\u00adele\u00admenten sowie Software f\u00fcr eingebettete Produkte, z.B. f\u00fcr fahrzeuginterne Kommunikation (CAN, FlexRay) und Securitymodulen f\u00fcr erh\u00f6hten Manipulationsschutz von Micro\u00adcontrollern („HSM“) beteiligt. Seit 2013 leitet er das konzernweite „Bosch Center of Competence Security“ bei ETAS.<\/p>\n Kontakt: markus.ihle@etas.com<\/p>\n Beitrag als PDF downloaden<\/a><\/strong><\/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>\n
\n<\/strong><\/p>\nMotivation und Beispiele<\/h2>\n
Environmental Hacks: Safety oder Security?<\/h2>\n
Ansatz f\u00fcr den Entwicklungsprozess<\/h2>\n
\n
Beispielhafte Umsetzung<\/h2>\n
a) Verkehrsschilder<\/h3>\n
b) Laser-Pointer<\/h3>\n
c) GPS Spoofing<\/h3>\n
Zusammenfassung<\/h2>\n
Referenzen<\/h2>\n
\nhttps:\/\/arxiv.org\/abs\/1707.08945<\/a>\u00a0(abgerufen am 30.07.2018)<\/p>\n
\n(abgerufen am 30.07.2018)<\/p>\n
\nhttps:\/\/www.aerokurier.de\/general-aviation\/haftstrafe-fuer-laser-blendung-in-berlin\/738030<\/a>\u00a0(abgerufen am 27.09.2018)<\/p>\n
\nhttps:\/\/www.ln-online.de\/Lokales\/Luebeck\/Anschlag-mit-Laserpointer-Busfahrer-am-Auge-verletzt<\/a>\u00a0(abgerufen am 24.07.2018)<\/p>\n
\nhttps:\/\/www.computerworld.com\/article\/3005436\/cybercrime-hacking\/black-hat-europe-it-s-easy-and-costs-only-60-to-hack-self-driving-car-sensors.html<\/a>\u00a0(abgerufen am 24.07.2018)<\/p>\n
\nhttps:\/\/www.heise.de\/newsticker\/meldung\/GPS-unter-Beschuss-Jamming-und-Spoofing-nehmen-zu-4038137.html<\/a>\u00a0(abgerufen am 27.09.2018)<\/p>\n
\nhttps:\/\/www.cnet.com\/news\/truck-driver-has-gps-jammer-accidentally-jams-newark-airport\/<\/a>\u00a0(abgerufen am 27.09.2018)<\/p>\n
\nhttps:\/\/hackaday.com\/tag\/gps-spoofing\/<\/a>\u00a0(abgerufen am 27.09.2018)<\/p>\nAutoren<\/h2>\n
\nAutomotive – unsere Trainings & Coachings<\/h2>\n
\nAutomotive – Fachwissen<\/h2>\n