Mehrseitig sichere Ad-hoc-Vernetzung von Fahrzeugen || Vorüberlegungen und Annahmen

KAPITEL 4

Vorüberlegungen und Annahmen

In diesem Kapitel wird zuerst ein Überblick über die diversen Systemteile einer VANET-Sicherheitsinfrastruktur gegeben, die im Rest der Arbeit genauer betrachtet werden. Die wei-teren Abschnitte beschäftigen sich mit grundlegenden Vorüberlegungen, die die Bewertungenund eigenen Vorschläge in den folgenden Kapiteln vorbereiten und unterstützen.

Konkret werden Möglichkeiten diskutiert, wie eine VANET-Identität gestaltet werden kann(Abschnitt 4.2). Aufbauend auf eine kurze Einführung in PKIs (Public Key Infrastructures)werden Überlegungen angestellt, wer als Trusted Third Party im VANET geeignet ist (Ab-schnitt 4.5). Abschnitt 4.3 betrachtet den Einsatz manipulationssicherer Hardware, Abschnitt4.6 die für das VANET in Frage kommenden Datenübertragungsstandards. Nach einigengrundsätzlichen Erläuterungen zum Routing (Abschnitt 4.7) und zu Intrusion Detection undAnreizsystemen (Abschnitt 4.8), wird der Leser am Ende des Kapitels (Abschnitt 4.9) mit denGrundannahmen der Arbeit vertraut gemacht, die zum großen Teil auf den Vorüberlegungenbasieren.

4.1 Architektur-Überblick

Die vier Anwendungskategorien „Beacons“ (A1), „Warnungen“ (A2), „Alarmsignale und An-weisungen“ (A3) und „Komfort-Dienste“ (A4) implizieren unterschiedliche Anforderungen andie Schutzziele Vertraulichkeit, Integrität und Verfügbarkeit (siehe Abschnitt 3.2). Dennochwird zum Erreichen der Schutzziele immer eine Sicherheitsinfrastruktur bzw. Sicherheitsar-chitektur benötigt, die eine Vertrauensbasis schafft, den Einsatz von Kryptographie ermöglichtund die anzuwendenden Schutzmechanismen beschreibt (vgl. [Eck08]).

Im Rahmen dieser Arbeit umfasst eine Sicherheitsinfrastruktur also alle techni-schen und organisatorischen Maßnahmen und Einrichtungen, die zum Erreichen derSchutzziele benötigt werden.

56 Kapitel 4 Vorüberlegungen und Annahmen

Basiselemente der Sicherheit

Single-Hop Sicherheit

Sch

utz

der

Priv

atsp

häre

Intr

usio

n D

etec

tion

/ Anr

eizs

yste

me

Multi-Hop Sicherheit

Alarmsignale und Anweisungen (A3)

Komfort-Dienste (A4)

Warnungen (A2)Routing

Ende-zu-Ende: Integrität, Vertraulichkeit, Authentifikation, Zurechenbarkeit

Beacons (A1)

Integrität

Vertraulichkeit

Zurechenbarkeit

Authentifikation

VANET-IdentitätPositions- und

Zeitdienste

PseudonymeRegistrierung

Teilnehmer-SperrungKryptographisches Material

Abbildung 4.1: Systemteile der Sicherheitsarchitektur

In diesem Abschnitt wird ein Überblick über die verschiedenen Systemteile einer solchenSicherheitsinfrastruktur gegeben. Er orientiert sich an den im vorhergehenden Kapitel vorge-stellten Anwendungskategorien und deren Schutzbedarf. Der Rest der Arbeit beschäftigt sichdann damit, für die einzelnen Teile konkrete Mechanismen auszuwählen bzw. zu entwickeln,die den gestellten Anforderungen entsprechen und diese im Sinne der mehrseitigen Sicherheitund Effizienz am besten erfüllen.

Wie in Abbildung 4.1 zu sehen, stehen auf unterster Ebene die Basiselemente der Sicherheit.Diese bilden den Vertrauensanker für die Mechanismen der höheren Schichten und stellenIdentitäten und Pseudonyme sowie zugehöriges kryptographisches Material bereit. Des Wei-teren sind hier Basismechanismen angesiedelt, wie die Möglichkeit zum Ausschluss von Teil-nehmern (Teilnehmer-Sperrung) oder sichere Zeit- und Positionsdienste.

Darauf aufbauend folgt die Single-Hop Sicherheit, die hauptsächlich die Absicherung der Be-acons (A1) betrifft. Diese stellen den Erstkontakt zwischen den Teilnehmern her und legen da-mit die Grundlage für die weitere Kommunikation, die in der Ebene derMulti-Hop Sicherheitbetrachtet wird. Diese umfasst die Nachrichten der anderen Anwendungskategorien (A2-A4)und das Routing der Nachrichten.

Sowohl bei der Single-Hop als auch bei der Multi-Hop Sicherheit werden Mechanismen be-nötigt, die einerseits den Schutz der Privatsphäre der Teilnehmer durchsetzen und andererseits

4.2 VANET-Identität 57

das korrekte Verhalten der Teilnehmer überwachen. Diese müssen ggf. Anreize zum korrektenVerhalten geben oder Sanktionen, wie z.B. eine Teilnehmer-Sperrung, auslösen können. Siesind daher vertikal zur Single-Hop und Multi-Hop Sicherheit angeordnet.

Der Vollständigkeit halber sei hier erwähnt, dass in [GFL+07] eine generische Sicherheits-architektur für VANETs vorgestellt wird, die dem hier vorgestellten und vom Autor dieserArbeit schon in [PNM06] publizierten Überblick sehr ähnlich ist. Sie enthält die gleichen Sys-temteile, verwendet zur Darstellung allerdings mehrere Sichten. Auf die genaue Darstellungder einzelnen Sichten wird an dieser Stelle verzichtet, da sie hier keinen wirklichen Mehrwertbieten.

4.2 VANET-Identität

Eine Identität liefert die Grundlage für jegliche Authentifikation, d.h. sie stellt ein gewissesWiedererkennungsmerkmal dar, anhand dessen man z.B. korrekt funktionierende bzw. koope-rative Teilnehmer zum VANET zulassen und fehlerhafte bzw. böswillige ausschließen kann(siehe dazu auch Abschnitt 4.8.1). Das impliziert natürlich, dass ein Knoten weder anonymauftreten noch seine Identität beliebig ändern können darf, da sonst sämtliche Maßnahmen derRegulierung ins Leere greifen. Weitere Informationen und eine Definition des Begriffs Iden-tität für mobile Netze im Allgemeinen sind in [KSW05] und [Kar03] zu finden. In [Kar03]wird zudem festgehalten, dass ohne Beteiligung einer Trusted Third Party keine verlässlichenIdentifikatoren1 generiert werden können.

Für diese Arbeit ist festzuhalten, dass eine VANET-Identität somit ein oder mehrere unab-änderliche Merkmale eines Knotens beinhalten muss, die ihn eindeutig charakterisieren undunterscheidbar von anderen machen. Die Natur einer solchen VANET-Identität ist zunächstnicht eindeutig festgelegt. Sie kann Identitätsmerkmale des Fahrzeugs, des aktuellen Fahrersoder von beiden zusammen beinhalten. Die Vor- und Nachteile der verschiedenen Möglich-keiten werden im Folgenden kurz erörtert.

4.2.1 Fahrzeugbezogene Identität

In VANETs treten neben eventuell personenbezogenen Daten in Masse fahrzeugbezogene, oftautomatisch versendete Daten (z.B. Beacons siehe Abschnitt 3.2.3) auf. Zudem ist es durch-aus möglich, dass der aktuelle Fahrer nicht für möglicherweise versendete Falschmeldungenverantwortlich ist, sondern diese von einem Defekt des Fahrzeugs oder von Manipulationenherrühren. Für diesen Fall erscheint eine fahrzeugbezogene Identität als am besten geeignet.

1Nach [Kar03] ist ein Identifikator „ein Merkmal (oder eine Gruppe von Merkmalen), welches geeignet ist, einObjekt zu identifizieren, d.h. seine Identität zweifelsfrei festzustellen, und welches den Kriterien der Identität(Eindeutigkeit, unveränderliche Verknüpfung, lebenslange Gültigkeit, keine Übertragbarkeit auf andere Objekte)genügt“.


Sollen gestohlene oder in Straftaten verwickelte Fahrzeuge verfolgt werden, müssen Identitäts-merkmale des Fahrzeugs (wie z.B. Fahrgestellnummer, Nummernschild usw.) als zwingendnotwendiger Bestandteil einer VANET-Identität betrachtet werden. Dies entspricht in digita-ler Form der gegenwärtigen Situation: Ein Nummernschild pseudonymisiert den Halter einesFahrzeugs, der Fahrer kann nicht mit Sicherheit bestimmt werden. Diese Metapher verwen-det z.B. auch [HCL04] und nennt die fahrzeugbezogene Identität „Electronic License Plate“ –elektronisches Nummernschild.

Mit dem traditionellen Nummernschild kann heute also – inzwischen auch durch optische Er-kennungssysteme, was aber vom Bundesverfassungsgericht verboten bzw. stark eingeschränktwurde (vgl. Abschnitt 3.1.1) – ein Fahrzeug und damit sein Halter eindeutig identifiziert wer-den. Dies schlägt sich auch in den gesetzlichen Regelungen nieder, die beispielsweise inDeutschland grundsätzlich den Halter eines Fahrzeuges haftbar machen (§7 StVG, Straßenver-kehrsgesetz in der aktuellen Fassung vom 18.4.2008)2. Mit einer fahrzeugbezogenen digitalenIdentität könnte also die aktuelle Gesetzeslage beibehalten werden. Ein solches Vorgehen wür-de zudem die Akzeptanz einer solchen VANET-Identität in der Bevölkerung erhöhen, da siemit der Rechtssituation bereits vertraut ist.

Eine Schwierigkeit besteht an dieser Stelle darin, sicherzustellen, dass die fahrzeugbezogeneIdentität untrennbar und unveränderlich mit dem Fahrzeug verbunden ist. Eine Manipulationdes Kennzeichens ist bereits strafbar (§22 StVG) und es werden physische Schutzmechanis-men, wie die sich beim Ablösen selbst zerstörenden Aufkleber, ergriffen. Eine vergleichba-re Möglichkeit für eine digitale fahrzeugbezogene Identität bietet hier manipulationssichereHardware, welche die VANET-Identität aufnimmt und untrennbar mit dem Fahrzeug verbun-den ist. „Untrennbar“ ist dabei so zu verstehen, dass schon der Versuch diese manipulations-sichere Hardware zu entfernen zu deren Zerstörung (oder zumindest zur Zerstörung der ge-speicherten Informationen) führt. Mehr zu manipulationssicherer Hardware folgt in Abschnitt4.3.

4.2.2 Personenbezogene Identität

Die zweite Variante sind personenbezogene VANET-Identitäten, die sich direkt auf den Fahrerdes entsprechenden Fahrzeugs beziehen, da alle Nachrichten direkt mit dessen Fahrweise bzw.dem Zustand seines Fahrzeugs zusammenhängen. Dieser Ansatz erleichtert auch die Rekon-struktion von Unfall- und Fahrerflucht-Situationen, bei denen bisher nur das Unfallfahrzeugund damit der Halter, nicht aber der Fahrer, mit Sicherheit bestimmt werden konnte, wenndieser sich dem Tatort entzogen hatte.

Dem steht jedoch – wie bereits erwähnt – die aktuelle Gesetzgebung gegenüber, die grundsätz-lich den Fahrzeughalter (§7 StVG) haftbar macht. Den Hinweis auf den Fahrzeughalter leistenohne großen Aufwand auch rein fahrzeugbezogene Identitäten, da die Exekutive bereits heute

2Der Fahrzeugführer ist allerdings auch ersatzpflichtig (§18 StVG).

4.2 VANET-Identität 59

die Halter über Dokumente wie Fahrzeugschein und -brief bzw. Zulassungsbescheinigung Teil1 und Teil 2 oder über ihre zentralen Speicher ermittelt.

Es erscheint allerdings angebracht, zumindest für diejenigen Teilnehmer eines VANETs per-sonenbezogene Identitäten zu verwenden, die über erhöhte Privilegien verfügen, wie z.B. Ein-satzkräfte der Polizei, Feuerwehr etc. Es stellt sich dann allerdings die Frage, wie entschiedenwerden kann, ob eine Person ihre Privilegien gerade benutzen darf. Ein Polizist sollte bei-spielsweise, wenn er außerhalb seiner Dienstzeit im Privat-KFZ unterwegs ist, keine Anwei-sungen an andere Verkehrsteilnehmer senden können. Dieses Problem adressieren die weiterunten diskutierten gemischten Identitäten.

Die Vielzahl möglicher Fahrer wirft auch die Frage auf, wo personenbezogene Identitätengespeichert werden sollten. Eine Vorinstallation auf dem Fahrzeug selbst scheidet aus, da mannicht vorhersehen kann, welche Personen es benutzen werden. Als weitere Variante eignensich auch die Fahrzeugschlüssel nicht: Zum Einen kann aus Kostengründen nicht für jedenFahrer ein eigener Schlüssel vorausgesetzt werden, zum Anderen läge die Verwaltung undSpeicherung des kryptographischen Materials ohne Ausweichmöglichkeit in den Händen derAutomobil- bzw. Schlüsselhersteller.

Elektronische Führerscheine hingegen bieten sich an: Jeder Fahrer muss ohnehin einen gül-tigen Führerschein besitzen und ihn bei Bedarf nachweisen3, d.h. mit sich führen. Das Spei-chern der Identität auf einem elektronischen Führerschein in Form einer Smartcard bedeutetalso kaum einen Komfortverlust für die VANET-Benutzer, es müsste allerdings der bisherigeFührerschein umgetauscht werden.

Bei dieser Lösung ergeben sich Synergieeffekte in Bezug auf die Neuregelung der Lenk- undRuhezeiten (VO 3820/85), die mittlerweile in Kraft getreten ist4. In Folge dieser Neuregelungwurden bzw. werden sog. Fahrerkarten an Führer von Kraftfahrzeugen ausgegeben, die unterVO 3820/85 fallen (hauptsächlich LKW und Busse). Die Fahrerkarte ist „ein von den Behör-den des Mitgliedstaates zugeteiltes entnehmbares, persönliches Übertragungs- und Speicher-medium eines Fahrers für dessen Identifizierung und die Speicherung der wichtigsten Daten“(Verordnung (EG) Nummer 2135/98, Anhang I B). Man könnte diese Fahrerkarte also ohnegroße Probleme als elektronischen Führerschein ausbauen und auch für die Identifizierung inVANETs benutzen.

Würde nun ein solcher elektronischer Führerschein vom Fahrzeug zwangsweise zum Startenvorausgesetzt, könnte sich ein Fahrzeughalter beim Verleihen seines Fahrzeugs an einen ande-ren Fahrer – egal ob privat oder gewerblich – gegen Ansprüche aus nicht von ihm verursachtenSituationen absichern. Außerdem könnte der Halter genau definieren, wer mit dem Fahrzeugfahren darf. Auch das Fahren ohne gültigen Führerschein könnte eingedämmt werden.

3Laut §2 Abs. 1 StVG ist die Fahrerlaubnis „durch eine amtliche Bescheinigung (Führerschein) nachzuwei-sen.“ Wer ihn während der Fahrt nicht mitführt, begeht eine Ordnungswidrigkeit nach §75 Nummer 4 FeV(vgl. [DDD04]).4Genauere Informationen zu dieser Verordnung sind beispielsweise in [Ind06] zu finden.


Ein solcher Zwang ist bisher rechtlich aber nicht durchzusetzen und darüber hinaus aus fol-genden Gründen auch nicht wünschenswert: Bei einem Identifizierungszwang durch das Fahr-zeug könnten sich z.B. Probleme ergeben, wenn ein Fahrzeug in einem Notfall bewegt werdenmüsste, aber kein nachweislich berechtigter Fahrer vor Ort ist. Unter Umständen könnte esauch passieren, dass sich der Halter versehentlich die Rechte an seinem Fahrzeug entzieht unddann nicht mehr damit fahren kann. Abgesehen von diesen Problemen ist es auch zum Schutzder Privatsphäre nicht wünschenswert, dass man sich grundsätzlich vor Fahrtbeginn vor demFahrzeug ausweisen muss.

4.2.3 Gemischte Identität

Bei diesem Ansatz, der Nachrichten sowohl dem Fahrzeug als auch dem Fahrer zurechen-bar macht, werden personen- und fahrzeugbezogene Identitätsmerkmale kombiniert. Sollenerhöhte Privilegien benutzt werden, müssen beide Identitäten das unterstützen. Anweisungen,z.B. zum Räumen einer Fahrbahn, wären somit nur gültig, wenn sie von einem berechtigtenFahrzeug (z.B. einem Krankenwagen) mit einem berechtigten Fahrer kommen. Dadurch kannverhindert werden, dass gestohlene Einsatzfahrzeuge zum Aussenden von Anweisungen überdas VANET missbraucht werden.

Nachteil dieser Variante ist, dass für die Erstellung von Bewegungsprofilen per se die meis-ten Informationen bereitgestellt werden. Sind die Identitäten ungeschützt in den Nachrichtenenthalten, kann ein Angreifer sowohl bestimmte Personen als auch bestimmte Fahrzeuge pro-blemlos verfolgen. Das Problem der Erstellung von Bewegungsprofilen ergibt sich aber auchbei den anderen Varianten, wenn die Identitäten ungeschützt verwendet werden. Unter un-geschützt ist dabei zu verstehen, dass die Identitäten einerseits im Klartext übertragen undandererseits auch nicht gewechselt werden.

Zudem entstehen möglicherweise Mehrkosten dadurch, dass zwei Identitäten benötigt werden:Es muss nämlich sowohl die fahrzeugbezogene Identität erzeugt und in manipulationssichererHardware im Fahrzeug gespeichert werden als auch die personenbezogene Identität auf einemelektronischen Führerschein.

4.2.4 Fazit

Ausgehend von der momentan geltenden Rechtslage und durchgeführten Praxis erscheint einefahrzeugbezogene Identität angemessen, mit deren Hilfe der Halter des Fahrzeugs ermitteltwerden kann. Auch im Hinblick auf die Akzeptanz der Nutzer erscheint eine solche Identitäts-wahl am geeignetsten, da eine solche VANET-Identität dem bekannten und akzeptierten Fahr-zeugkennzeichen entspricht. Für spezielle Personengruppen wie Polizisten sollten allerdingszusätzlich personenbezogene Identitäten verwendet werden, an die ihre speziellen Privilegiengebunden sind. Die Privilegien gelten dann nur im Zusammenspiel von fahrzeugbezogener und

4.3 Manipulationssichere Hardware 61

personenbezogener Identität, wodurch die aktuelle Situation insoweit verbessert wird, dass ge-stohlene Einsatzfahrzeuge nicht zum Versenden von Anweisungen im VANET genutzt werdenkönnen.

Für bestimmte Situationen, wie z.B. für den gewerblichen Verleih von Fahrzeugen, erscheint essinnvoll zusätzlich zur fahrzeugbezogenen auch eine personenbezogene Identität für „norma-le“ Fahrer zu benutzen, um den Halter in gewissem Maße vor Ansprüchen Dritter zu schützen.In diesem Fall ist allerdings eine nachträgliche Identifizierung des Fahrers ausreichend. Diepersonenbezogene Identität muss hier also nicht zwangsläufig im VANET verwendet werden,sondern könnte zusammen mit der Fahrzeit und ggf. anderen Daten in manipulationssichererHardware im Fahrzeug gespeichert werden. Diese Daten sind dann allerdings vor unbefugtemAuslesen zu schützen. Ein elektronischer Führerschein zur Zugangskontrolle zum Fahrzeugerscheint als Option durchaus sinnvoll, sollte allerdings keinesfalls zwangsweise zur VANET-Identität gehören.

4.3 Manipulationssichere Hardware

In diesem Abschnitt geht es darum, wie und wo das geheime kryptographische Material, dasfür die fahrzeugbezogene Identität und die Umsetzung der Schutzmechanismen benötigt wird,erzeugt und gespeichert werden kann.

4.3.1 Notwendigkeit

Wie in Abschnitt 3.1.1 schon angedeutet, ist der Schutz des benötigten kryptographischen Ma-terials im VANET verglichen mit der Situation in anderen Netzen relativ schwer zu erreichen,da Fahrzeuge und stationäre Knoten oft in periodischen oder für Angreifer vorhersehbarenZeitabständen den persönlichen Vertrauensbereich verlassen (z.B. Bau eines Fahrzeugs, Re-paraturen, Kundendienste, Polizeikontrollen, Wechseln von Firmenfahrzeugen unter den Mit-arbeitern eines Unternehmens usw.). Zudem kann – wie aus Abschnitt 3.3 ersichtlich – imVANET jede Partei, d.h. insbesondere auch Insider, wie Fahrer oder Halter eines Fahrzeugs,Angreifer sein. Es wird daher ein Vertrauensbereich benötigt, der gegen unbefugten Zugriffjeglicher Partei effektiv schützt.

Die einzige Möglichkeit einen solchen Schutz zu erreichen, ist die Kapselung der zu schüt-zenden Daten in manipulationssicherer Hardware (Tamper Resistant Hardware, TRH, auch:TPM – Tamper Proof Module bzw. Trusted Platform Module oder TPD – Tamper Proof De-vice). Diese TRH verfügt über einen gesicherten Speicher beispielsweise für Zertifikate undprivate Schlüssel und einen Kryptoprozessor zur Generierung von Schlüsselpaaren und zurDurchführung von Ver-/Entschlüsselungs- bzw. Signieroperationen.

Die gespeicherten privaten Schlüssel verlassen zur Entschlüsselung oder Signaturgenerierungdie TRH nicht. Vielmehr werden die zu entschlüsselnden bzw. signierenden Daten an die TRH


geliefert und die notwendigen Berechnungen werden durch den internen Prozessor durchge-führt. Lediglich das Ergebnis der Operation wird bekannt gegeben.

Eine Art von TRH stellen spezielle Smartcards dar, wie z.B. die SIM-Card im GSM-Netz.Solche Smartcards sind hier allerdings nicht geeignet, da sie meist keinen hohen Schutz bie-ten und im VANET zudem fahrzeugbezogene Identitäten eingesetzt werden sollen (siehe Ab-schnitt 4.2). Die VANET-Identität (und damit auch die TRH, die diese Identität speichert)muss also untrennbar mit dem Fahrzeug verbunden sein. Um die geforderte Zurechenbarkeitzu erhalten, muss sichergestellt werden, dass die Daten unumgänglich zerstört werden, wennversucht wird, die TRH aus dem Fahrzeug zu entfernen.

In [RH05a] wird der Vorschlag gemacht, die Speicherfähigkeiten der TRH auszubauen unddamit einen Event Data Recorder (EDR) zu realisieren. Dieser soll, ähnlich einer Black Boxin Flugzeugen, die internen Fahrdaten und die empfangenen und verschickten Daten sichern.Diese Daten sollen periodisch überschrieben werden und z.B. bei Unfällen helfen, die letztenMinuten rekonstruieren zu können.

Es wäre auch denkbar, dass ein solcher Speichervorgang automatisch oder manuell vom Fahrerausgelöst wird, um Beweismittel zu sichern. Auslöser könnten z.B. Unstimmigkeiten bei derAuswertung der Nachrichten und dem Vergleich mit den eigenen Sensoren sein. Diese Datenkönnen dann unter Umständen helfen, Angriffe zu erkennen, bestimmten Angreifern zuzuord-nen und entsprechende Schritte einzuleiten. Auch empfangene Anweisungen und die darauffolgenden Ereignisse könnten gespeichert werden, um belegen zu können, dass man diesenFolge geleistet hat. Da viele Warnungen auf einer Aggregation anderer Daten und Nachrich-ten beruhen, sollten alle zu einer Warnung führenden Informationen gespeichert werden. Da-durch kann einer ungerechtfertigten Bestrafung vorgebeugt werden, die eine ungewollt, d.h.aufgrund einer lokalen Fehleinschätzung der Verkehrslage beruhende, falsche Warnung nachsich ziehen würde. Bei der Speicherung ist auf Datensparsamkeit und eine restriktive Zugriffs-kontrolle zu achten, so dass diese Daten nicht von Unbefugten ausgelesen werden können. Isteine gewisse Frist verstrichen, in der man ggf. strafrechtlich belangt werden könnte, sind dieDaten zu überschreiben.

Nach [BH07] ist das größte Hemmnis für den Einsatz von TRH momentan deren hohe Kosten.Die Autoren sind allerdings zuversichtlich, dass die Preise für die in den Fahrzeugen benötigteTRH in vernünftige Regionen sinken werden. Neben dem verstärkten Wettbewerb bei derHerstellung von TRH nennen sie vor allem die Economies of Scale5, die durch die große Zahlan Fahrzeugen entstehen, die TRH benötigen.

4.3.2 Sicherheit

Die Sicherheit von TRH kann nach dem FIPS 140-Standard [Nat01] zertifiziert werden, dervier Stufen definiert. Stufe 4 stellt dabei die sicherste Stufe dar, aber auch bei Stufe 3 wird5Dieses Prinzip besagt, dass mit steigendem Produktionsvolumen Skaleneffekte z.B. beim Einkauf und der Ferti-gung auftreten, die das Endprodukt (wesentlich) billiger machen.

4.4 Public-Key-Infrastruktur 63

schon gefordert, dass Öffnungsversuche mit hoher Wahrscheinlichkeit festgestellt und Gegen-maßnahmen eingeleitet werden müssen. Aus [Nat07] ist ersichtlich, dass im Januar 2007 etwa21% der zertifizierten Produkte Stufe 3 und etwa 1,5% Stufe 4 erfüllten. Es ist anzumerken,dass auch einige Produkte der Stufe 3 beim Prüfteil der physischen Sicherheit Level 4 errei-chen.

Beispiele für Produkte der Stufe 4 sind AEP Kyper Enterprise, IBM 4758-002 PCI Cryp-tographic Coprocessor oder IBM eServer Cryptographic Coprocessor Security Module. Fürden schon etwas älteren IBM 4758 wurden zwar zwei erfolgreiche Angriffe publiziert (sie-he [ABC+05], [CB02]), diese wurden aber auf Teile von mitgelieferten Beispielanwendungenausgeführt, die nicht zertifiziert waren. Auf die zertifizierte Hard- und Software ist bisher nochkein erfolgreicher Angriff publiziert worden (vgl. [KM06]). Um den Rahmen der Arbeit nichtzu sprengen, soll hier nicht genauer auf Angriffe und Schutzmaßnahmen für TRH eingegan-gen werden6. Es sei allerdings – wie auch in [AK96] und [Sch04] – darauf hingewiesen, dasses wohl auf Dauer keine Garantie für die Sicherheit einer bestimmten TRH gibt.

Trotzdem wird die Verwendung von TRH im VANET-Bereich durchgängig als Lösung fürden Schutz des benötigten kryptographischen Materials angesehen (vgl. z.B. [LBH+06],[GFL+07], [PBH+07], [FRF+07], [JARH06], [RPA+07], [RH07]). Gründe dafür sind, dassdie korrekte Funktionsweise und Unversehrtheit der TRH bei den periodischen Untersuchun-gen des Fahrzeugs (z.B. TÜV) überprüft werden kann und die Aufgaben der TRH sehr speziellsind. Durch diese Spezialisierung kann die benötigte API vergleichsweise klein gehalten wer-den, wodurch sie besser gegen mögliche Angriffe abzusichern ist. Ein weiterer Grund ist, dassman schlicht irgendeinen Vertrauensanker benötigt, der auch gegen Angriffe durch InsiderSchutz bietet.

4.3.3 Fazit

Diese Arbeit schließt sich der in der Literatur vorherrschenden Meinung an und es wird imFolgenden davon ausgegangen, dass ausreichend sichere TRH existiert und in den Fahrzeu-gen eingesetzt wird. Die Generierung des benötigten kryptographischen Materials sollte – so-weit möglich – auch in dieser TRH erfolgen, um eine Kapselung der geheimen Schlüssel inder TRH zu erreichen. Vorteil dieser Vorgehensweise ist, dass keine Partei Kenntnis von denSchlüsseln erlangen kann.

4.4 Public-Key-Infrastruktur

Wie in den Abschnitten 3.1.1 und 3.1.2 schon angedeutet, kann asymmetrische Kryptogra-phie zum Schutz der Vertraulichkeit und der Integrität eingesetzt werden. Ohne weitere Maß-6Ein guter Überblick über Angriffe und Schutzmaßnahmen ist in [Wei00] (bzw. der aktualisierten Version [Wei08])zu finden. Eine Taxonomie der möglichen Angriffe liefert [RW03], viele Schutzmechanismen werden in [RRC04]vorgestellt.


nahmen und Einrichtungen ist es jedoch nicht möglich, folgende Probleme und Aufgaben zubewältigen (vgl. [Sch01], [NDJB02], [Rei06]):

• Ein öffentlicher Schlüssel trägt keinerlei Authentizitätsmerkmale, d.h. es ist nicht mög-lich, ihn zweifelsfrei einem Besitzer zuzuordnen. Dies ermöglicht einerseits Man-in-the-Middle-Attacken der Form, dass Angreifer die Übertragung eines öffentlichen Schlüs-sels (von einer Schlüsseldatenbank oder dem rechtmäßigen Besitzer) abfangen und ihngegen den eigenen austauschen können (vgl. [Eck08]). Werden nun Nachrichten mitdiesem Schlüssel verschlüsselt, kann der Angreifer die Nachricht mit dem passendenprivaten Schlüssel entschlüsseln und für den eigentlichen Adressaten transparent wie-der verschlüsseln, was zum Verlust der Vertraulichkeit und – wenn der Angreifer dieNachricht modifiziert – auch zum Verlust der Integrität führt. Andererseits könnte einAngreifer z.B. mit der Begründung, der verwendete Schlüssel sei nicht seiner, abstrei-ten, eine vorliegende Signatur erstellt zu haben, wodurch auch die Zurechenbarkeit vonNachrichten nicht mehr gegeben ist.

• Ein Schlüsselpaar (ein öffentlicher und ein dazu passender privater Schlüssel) besitztkeinerlei Gültigkeitsmerkmale. Wird ein privater Schlüssel von einem Angreifer gestoh-len oder auf andere Weise ermittelt, gibt es keine Möglichkeit, dieses kompromittierteSchlüsselpaar derart zu markieren (sperren), dass damit erzeugte Signaturen und Chif-frate als ungültig erkannt werden.

• In einem großen System, wie z.B. einem VANET, sind zentrale Forderungen und Re-geln schwierig in konsistenter Weise durchzusetzen. Beispiele für solche Forderungenund Regeln sind vorgeschriebene (Mindest-)Schlüssellängen, periodischer Schlüssel-wechsel, zentrale Registrierung von öffentlichen Schlüsseln, automatische Sperrung vonausscheidenden Mitgliedern etc.

Es muss also durch einen zusätzlichen Mechanismus bei allen Netzteilnehmern gleichermaßendas Vertrauen in die Zuordnung Schlüssel–Besitzer geschaffen werden. Im Gegensatz zumWeb of Trust (siehe Abschnitt 6.2.3) leistet dies im Fall einer Public-Key-Infrastruktur (PKI)eine unabhängige dritte Instanz, die das Vertrauen aller Teilnehmer genießt, das Trust Center(auch Trusted Third Party).

4.4.1 Komponenten

Dieses Trust Center besteht aus folgenden Komponenten, deren genaue Funktion beispiels-weise in [NDJB02] oder [Sch01] nachgelesen werden kann. Es müssen nicht zwingend alleKomponenten vorhanden sein.

Zertifizierungsinstanz (CA)

Dies ist die zentrale, vertrauenswürdige Instanz, die die Aufgabe hat, Identitäten zu zertifizie-ren. Dazu werden von ihr alle Informationen für ein Zertifikat entgegengenommen und mit

4.4 Public-Key-Infrastruktur 65

ihrem privaten Schlüssel digital signiert. Die typischen Bestandteile eines Zertifikats werdenin Abschnitt 4.4.2 kurz erläutert.

Die geeignete Auswahl des CA-Betreibers ist sehr wichtig, da die Nutzer ihm vertrauen müs-sen. Des Weiteren müssen sehr hohe Sicherheitsvorkehrungen zum Schutz der CA getroffenwerden, da sie ein sehr attraktives Ziel für Angreifer darstellt: Gelingt es, den privaten Schlüs-sel der CA zu stehlen oder anderweitig herauszufinden, müssen alle herausgegebenen Zerti-fikate ab diesem Zeitpunkt als ungültig betrachtet werden, da der Angreifer nun selbst in derLage ist, Zertifikate ununterscheidbar von den „echten“ zu erstellen.

In großen PKIs ist es zudem sinnvoll, nicht eine einzige CA, sondern eine CA-Hierarchieeinzusetzen (vgl. [NDJB02]). In einer solchen Hierarchie zertifiziert die erste, oberste CA(Wurzelinstanz, Root-CA) weitere untergeordnete CAs, die dann die eigentlichen Teilnehmer-zertifikate ausstellen. Dies wirkt sich einerseits positiv auf die Sicherheit des Gesamtsystemsaus, da die Root-CA die meiste Zeit offline ist, andererseits müssen dann allerdings auch dieCAs der tieferen Ebenen entsprechend abgesichert werden.

Registrierungsinstanz (RA)

Die RA ist die Anlaufstelle für einen Zertifikatsantrag. Sie leitet nach eingehender Prüfung dieDaten eines Antragstellers an die CA weiter, die schließlich durch ihre Signatur das Zertifikatgeneriert. Die Registrierungsinstanz nimmt in ihrer vorgelagerten Stellung Last von der Zer-tifizierungsinstanz und erhöht zugleich deren Sicherheit, da sie die normalen Teilnehmer vonder CA abschirmt.

Je nach gewünschtem Sicherheitsgrad kann die Prüfung rein maschinell oder manuell erfolgen.Die RA kann als eigenständige Komponente oder als Teil der CA implementiert werden. Beigrößeren Netzen, wie dem VANET, sind mehrere lokale Registrierungsinstanzen aufgrund derleichteren Erreichbarkeit für die Teilnehmer von Vorteil.

Zertifikatsspeicher (DIR)

Die Public Keys und die zugehörigen Zertifikate sollten für alle Netzteilnehmer jederzeit ab-rufbar sein, um gesicherte Kommunikation zwischen zwei Teilnehmern zu ermöglichen. Üb-licherweise werden für die Speicherung dieser Zertifikate Verzeichnisdienste wie das Light-weight Directory Access Protocol (LDAP [Ser06], vgl. [Eck08]) eingesetzt, die auch die ge-zielte Suche nach Schlüsseln erlauben.

Sperrinstanz (REV )

Diese Instanz kennzeichnet im Auftrag des Schlüsselinhabers oder einer administrativen Funk-tion ein Schlüsselpaar bzw. das zugehörige Zertifikat als ungültig und sperrt es damit. Dies


wird z.B. dann nötig, wenn der private Schlüssel dieser Identität kompromittiert worden ist,sich Zertifikatinhalte ändern, die Identität in der PKI nicht mehr genutzt wird oder ein Teil-nehmer aus dem Netz ausgeschlossen werden soll.

Zeitstempeldienst (TSS)

Wie schon in Abschnitt 3.1.2 erläutert, benötigt das Schutzziel der Zurechenbarkeit eine ver-lässliche, überprüfbare Zeitangabe als Bestandteil einer Signatur. Solche digital signiertenZeitstempel liefert der TSS, der beispielsweise vom deutschen Signaturgesetz als Bestandteileines Trust Centers vorgeschrieben wird (vgl. [Eck08]).

Schlüsselwiederherstellungsinstanz (REC)

Diese Instanz übernimmt die – aus Sicherheitssicht fragwürdige – Aufgabe, private Schlüs-sel bei Verlust oder autorisierten Anfragen z.B. der Exekutive wieder herzustellen und demanfragenden Teilnehmer auszuhändigen. REC wird in den meisten Trust Centern nicht imple-mentiert, da allein der Teilnehmer Kenntnis von seinem privaten Schlüssel besitzen sollte. Esist grundsätzlich aber natürlich möglich, dass das Schlüsselpaar des Antragstellers nicht vonihm selbst, sondern von der CA oder einem Schlüsselgenerierungsserver erzeugt wird.

4.4.2 Zertifikate und ihr Management

Nach [NDJB02] ist ein digitales Zertifikat „eine überprüfbare Verknüpfung zwischen einerIdentität und dem Public-/Private-Schlüsselpaar, das sich im Besitz des Inhabers der Identi-tät befindet“. Eine konkrete technische Umsetzung wird beispielsweise im Standard X.509[HPFS02] beschrieben.

In einem solchen X.509-Zertifikat werden neben dem eindeutigen Benutzernamen (der Identi-tät) und dessen öffentlichem Schlüssel auch Informationen über die Zertifizierungsstelle, denverwendeten Signaturalgorithmus und die Gültigkeit des Zertifikats eingebettet. Durch dieangefügte digitale Signatur der ausgewiesenen Zertifizierungstelle wird die Zuordnung Teil-nehmer – öffentlicher Schlüssel für alle anderen Teilnehmer beweisbar.

Abbildung 4.2 zeigt die Struktur eines solchen Zertifikats, in dem auch noch die Versionsnum-mer des Standards und eine eindeutige Seriennummer enthalten ist. Seit Version 2 des Stan-dards sind eine eindeutige Ausstellerkennung und eine eindeutige Benutzerkennung enthalten,Version 3 lässt zudem Erweiterungen zu, mit denen anwendungsabhängig weitere Informatio-nen im Zertifikat gespeichert werden können. Konkrete in X.509v3 festgehaltene Standar-derweiterungen sind z.B. Einsatzzweck des öffentlichen Schlüssels (Verschlüsseln, Signieren,Zertifizieren etc.), Richtlinienerweiterungen, erweiterte Teilnehmer- und Ausstellerinforma-tionen etc.

4.5 Trusted Third Party 67

X.509 VersionSeriennummerSig-Algorithmus

GültigkeitAussteller

Name des BenutzersÖffentlicher Schlüssel

Aussteller-IDBenutzer-ID

Opt. Erweiterungen

Digitale Signatur

v1

v1

Erweiterung v2

Erweiterung v3

Abbildung 4.2: Struktur eines X.509-Zertifikats

In manchen Fällen kann es sinnvoll sein, teilnehmerbezogene Attribute, Rechte oder Privilegi-en nicht direkt in diesen Erweiterungsfeldern zu speichern, sondern diese in eine separate Da-tenstruktur auszulagern. Diese werden Attribut-Zertifikate genannt und gleichen in ihrem Auf-bau – bis auf das Fehlen des öffentlichen Schlüssels – herkömmlichen (Schlüssel-)Zertifikaten(vgl. [NDJB02], [Sch01]).

Der Lebenszyklus von Zertifikaten umfasst nach [Sch01] und [NDJB02] im Allgemeinen fol-gende Stationen:

1. Enrollment: Der Begriff Enrollment bezeichnet die Erstanmeldung eines Teilnehmers,verbunden mit der Generierung seines Zertifikats. Der initialen Feststellung der Identitätdes Antragstellers durch die RA kommt hier eine zentrale Bedeutung zu.

2. Zertifikatserneuerung: Ist das Schlüsselpaar bzw. Zertifikat am Ende seiner Lebensdau-er angelangt, muss es erneuert werden. Die Identitätsprüfung ist hier einfacher als beimEnrollment: Es genügt eine Signatur mit dem alten Schlüssel, um die Zertifikatserneue-rung durchzuführen.

3. Gültigkeitsende: Neben dem normalen Ablauf eines Zertifikats am Ende seiner Gültig-keit, kann der Fall eintreten, dass ein Zertifikat auf schnellstemWege gesperrt und dieserUmstand allen Teilnehmern bekannt gemacht werden muss. Ein solcher Zertifikatsrück-ruf (Revocation) ist z.B. nötig, wenn ein privater Schlüssel kompromittiert wurde oderein Teilnehmer aus dem Netz ausgeschlossen werden soll.

4.5 Trusted Third Party

In diesem Abschnitt soll erörtert werden, wer im VANET als vertrauenswürdiger Dritter (Trus-ted Third Party, TTP) in Frage kommt und somit Betreiber von Komponenten der Sicherheits-


infrastruktur sein kann, in die von den Teilnehmern ein gewisses Vertrauen gesetzt werdenmuss. Betreiber der Sicherheitsinfrastruktur werden in dieser Arbeit all diejenigen Stellen,Unternehmen, Organisationen etc. genannt, die eine oder mehrere Aufgaben in einer Sicher-heitsinfrastruktur wahrnehmen. Die Komponenten einer PKI (siehe Abschnitt 4.4) können bei-spielsweise auf mehrere Instanzen verteilt (z.B. hierarchisch strukturierte CAs) oder in einerInstanz zusammengefasst werden (z.B. können RA und/oder die Schlüsselgenerierung in dieCA integriert werden).

Wichtig ist, dass Betreiber kritischer Komponenten von allen Parteien als TTP akzeptiert wer-den oder zumindest das Gesamtsystem so konstruiert ist, dass alle Parteien Vertrauen in dasSystem haben können. Der Betreiber der CA wird hier stellvertretend betrachtet, um geeig-nete TTPs für das VANET zu identifizieren. Als Betreiber einer CA kommen grundsätzlichfolgende Instanzen in Frage:

• Automobilhersteller

• Unabhängige Organisationen

• Staatliche Stellen

• Kombinationen daraus

4.5.1 Auswahlkriterien

Der Vorschlag staatliche Stellen oder Automobilhersteller als Betreiber der CA zu verpflichten,wird bereits in [RH05b] und [PP05] gemacht. Die Autoren entscheiden sich allerdings nichtfür eine bestimmte Variante und geben auch keine Entscheidungskriterien an. In dieser Arbeitwerden folgende Kriterien für die Auswahl vorgeschlagen:

• Bestehendes Vertrauen: Die Parteien des VANETs sollen schon möglichst viel Vertrau-en in die jeweilige Instanz haben, d.h. sie sollten dieser zutrauen, persönliche Datenadäquat schützen zu können und zu wollen. Dieses Vertrauen kann beispielsweise inschon bestehenden Beziehungen begründet sein.

• Technische Kompetenzen: Die Instanz sollte technisch dazu in der Lage sein, eine CAzu betreiben.

• Rechtliche Kompetenzen: Die Instanz sollte das rechtliche Know-How haben, um denBetrieb einer CA gesetzeskonform aufzubauen.

• Zugriff auf Fahrzeuge: Die Instanz sollte möglichst einfach Zugriff auf die Fahrzeu-ge haben, um beispielsweise Wurzelzertifikate oder kryptographisches Material für diefahrzeugbezogenen Identitäten zu verteilen und die korrekte Funktionsweise der TRHzu prüfen.

• Enrollment: Die Prüfung der Identität des Antragstellers soll ohne großen Aufwand be-werkstelligt werden können. Dazu gehört ein relativ dichtes Netz an geographisch ver-teilten RAs mit entsprechend geschulten Mitarbeitern.


BestehendesVertrauen

TechnischeKompetenzen

RechtlicheKompetenzen

ZugriffaufFahrzeuge

Enrollm

ent

KomplexitätdesSystems

Automobilhersteller – + – ++ – +

Banken +(+) ++ ++ – ++ –

Datenschutzorganisationen ++ ++ ++ – – –

Kraftfahrtsämter +(+) ++ ++ + ++ +

Tabelle 4.1: Übersicht über die untersuchten CA-Betreiber

• Komplexität des Systems: Das entstehende PKI-Gebilde soll möglichst einfach und derAufwand für die Verteilung der Wurzelzertifikate nicht zu hoch sein.

Tabelle 4.1 fasst die Ergebnisse der Untersuchung kurz zusammen. Sie bezieht sich dabei aufobige Kriterien. – steht für nicht erfüllt, + für erfüllt und ++ für sehr gut erfüllt.

4.5.2 Automobilhersteller

Mit den Automobilherstellern als CAs wäre es sehr leicht, jedes Fahrzeug mit den aktuellenCA-Zertifikaten und den Zertifikaten für die fahrzeugbezogene Identität auszustatten, da diesevor Auslieferung an den Kunden einfachen Zugriff auf die Fahrzeuge haben. Voraussetzungist eine Standardisierung unter den Herstellern, die sich auf ein Zertifizierungssystem einigenmüssten.

Für diese Unternehmen wäre es allerdings schwierig, in jedem Land die gesetzlichen Vor-schriften zu beachten und dieselben Sicherheits- und Qualitätsniveaus zu erreichen. Die Diens-te der CA müssten von jedem der weltweit verteilten Unternehmensstandorte aus erreichbarsein. Außerdem fällt der Betrieb eines Trust Centers nicht in die Kernkompetenzen dieserUnternehmen.

Das Enrollment ist hier sehr schwierig durchzuführen, da die Automobilhersteller dazu erstgeeignete Infrastruktur schaffen müssten. Sie müssten flächendeckend regionale RAs aufbauenund ihre Kompetenzen bei der Speicherung personenbezogener Daten stark erweitern. Diesalles bringt hohe Investitionen für Aufbau und Unterhalt mit sich.

Auch aus Sicht der VANET-Nutzer sind Automobilunternehmen nicht der ideale Ort, an dempersonenbezogene Daten gesammelt werden sollten. Zwar wird den Automobilunternehmensicherlich Kompetenz bei der Fahrzeugherstellung zugesprochen, den Schutz ihrer Privatsphä-re werden aber die wenigsten Menschen in die Hände dieser gewinnorientierten Unternehmen


legen wollen. Um das Vertrauen in sie zu fördern, könnten diese Unternehmen den Schutz derPrivatsphäre und andere Schutzziele selbst zusichern, z.B. über eine Selbstverpflichtung, einevertragliche Zusicherung gegenüber dem Endkunden etc. (vgl. [FHK95]).

4.5.3 Unabhängige Organisationen

Hier kommen Organisationen in Frage, denen viele Menschen z.B. aufgrund einer bestehendenBeziehung bereits vertrauen. Ein Beispiel hierfür wären Banken. Diese besitzen Vertrauens-beziehungen zu ihren Kunden und haben auch Erfahrung im Betrieb von Trust Centern. DesWeiteren müssen sie vergleichsweise hohe Sicherheits- und Qualitätsniveaus erreichen undsich an die gesetzlichen Gegebenheiten in vielen Ländern anpassen. Sie sind es gewohnt sichan Standards zu halten, da sie sonst im nationalen und internationalen Finanzverkehr keineTransaktionen tätigen könnten. Viele Banken haben zudem ein Netz von Filialen, die zumEnrollment benutzt werden könnten. Auch heute nehmen die Bankmitarbeiter schon Identifi-zierungsaufgaben wahr und gehen mit persönlichen Daten um, beispielsweise beim Eröffneneines neuen Kontos.

Problematisch ist hier die Ausstattung der Fahrzeuge mit Zertifikaten und Prüfung der TRH, daBanken normalerweise keinen Zugriff auf die Fahrzeuge ihrer Kunden haben. Des Weiterenwürden durch die Vielzahl an Banken wahrscheinlich relativ viele Wurzelzertifikate entste-hen, die aufgrund der internationalen Tätigkeit vieler Banken in allen Fahrzeugen weltweitgespeichert werden müssten. In letzter Zeit ist das Vertrauen in Banken zudem durch immerwieder auftauchende Probleme beim Online-Banking und die globale Immobilienkrise etwaszurückgegangen (vgl. [Har08]).

Ein anderes Beispiel wären unabhängige Datenschutzorganisationen, wie sie beispielsweiseden Datenschutzbeauftragten der Länder unterstehen. Diese Stellen setzen sich für den Schutzder Privatsphäre der Bürger ein und sind unabhängig von den Interessen anderer Organisatio-nen. Durch die staatliche Finanzierung sind sie auch nicht auf Gewinnmaximierung aus undes besteht für die Teilnehmer des Netzes keine Gefahr, dass ihre Daten missbraucht werden,um damit Gewinne zu erzielen.

Es ist viel Know-How vorhanden, was die Gesetzeslage beim Datenschutz betrifft, und auchder technische Betrieb eines Trust Centers sollte problemlos möglich sein. Das unabhängigeLandeszentrum für Datenschutz Schleswig-Holstein (ULD) betreibt beispielsweise kostenloseMixe, die zum anonymen Surfen im Internet benutzt werden können (siehe [URL08w]). Auchin diesem Beispiel stellt der Zugriff auf die Fahrzeuge das größte Problem dar. Zudem wäre dieZahl der im Fahrzeug benötigten Wurzelzertifikate (wie auch im Fall der Banken) sehr groß.Die lokale Präsenz ist nicht so gut ausgeprägt wie bei den Banken und müsste erst ausgebautwerden.


4.5.4 Staatliche Stellen

Von den staatlichen Stellen bieten sich Kraftfahrtsämter als Betreiber der CA an. Solchestaatliche Kraftfahrtsämter gibt es in praktisch allen Ländern. Sie sind nach den aktuellengesetzlichen Vorschriften geschaffen und verfügen über bereits ausgebaute Infrastruktur, umeine große Teilnehmerzahl zu bewältigen. In diesem Abschnitt soll das deutsche Kraftfahrt-Bundesamt (KBA) stellvertretend für die nationalen Kraftfahrtsämter diskutiert werden.

Das KBA betreibt seit August 2005 ein Trust Center für das Zentrale Kontrollgerätekarten-register (ZKR) im Rahmen der Einführung des Digitalen EG-Kontrollgerätes7 (vgl. [KB06]).Die Einführung des Digitalen EG-Kontrollgerätes steht im Zusammenhang mit der Neurege-lung der Lenk- und Ruhezeiten (VO 3820/85), die schon in Abschnitt 4.2 angesprochen wurde.Im Folgenden sollen daher nochmals die relevanten Elemente kurz angesprochen werden. Ge-nauere Informationen sind in Verordnung (EG) Nummer 2135/98, [Ind06] oder [KB07a] zufinden.

• Fahrerkarte: Diese speichert Lenk- und Ruhezeiten und enthält die Identitätsdaten desFahrers. Diese Daten müssen alle 28 Tage auf Datenspeicher gesichert werden.

• Unternehmenskarte: Diese weist das Unternehmen aus und ermöglicht die Anzeige, dasHerunterladen und den Ausdruck der Daten, die im Kontrollgerät gespeichert sind.

• Werkstattkarte: Diese dient zur Prüfung/Reparatur und Kalibrierung des digitalen EG-Kontrollgerätes, sowie zum Herunterladen der Daten und zur Datensicherung.

• Kontrollkarte: Diese ermöglicht den unbeschränkten Zugriff auf gespeicherte Daten.

Das KBA stellt diese Karten aus und ist für die Verwaltung der PKI zuständig, auf der diefür die Autorisierung der unterschiedlichen Karten notwendige Authentifizierung basiert. DasKBA setzt also bereits jetzt viele Aufgaben um, die in VANETs in ähnlicher Form zu be-wältigen sind. Es ist also sowohl technisch als auch rechtlich sehr gut zum Betrieb einer CAgeeignet.

Das Enrollment kann bei den Zulassungsstellen des KBA8 durchgeführt werden. Sie erfüllenbereits jetzt viele Voraussetzungen:

• Sie sind den Fahrzeughaltern vertraut als diejenige Stelle, die staatliche Belange imFahrzeugwesen vertritt.

• Sie sind regional sehr gut verfügbar und haben ihren Sitz zentral in Landratsämtern undähnlichen staatlichen Verwaltungseinrichtungen.

• Sie sind bereits jetzt mit ihrer Zentrale, dem KBA, vernetzt.

• Sie verfügen über geschultes Personal, das den Umgang mit personenbezogenen Datengewohnt ist.

7Hinter diesem Begriff verbergen sich digitale Fahrtenschreiber, die ihre analogen und nicht fälschungssicherenPendants verpflichtend ab 1. Mai 2006 ablösen, vgl. [Hei06a].8Beispielhaft für die entsprechenden staatlichen Institutionen anderer Länder.


Es ist lediglich der Prozess der Fahrzeugzulassung um die Prüfung und Weitergabe der öf-fentlichen Schlüssel der fahrzeugbezogenen Identität an die CA und die Erzeugung und Rück-übertragung der Teilnehmerzertifikate zu erweitern.

Wird das jeweilige nationale Kraftfahrtsamt zur CA, ist die Zahl der weltweit existierendenWurzelzertifikate vergleichsweise klein. Zudem müssen nicht alle Wurzelzertifikate im Fahr-zeug vorhanden sein, sondern nur die Zertifikate der betreffenden Region, z.B. für Europa,Afrika, Süd- oder Mittelamerika, die leicht zu bestimmen sind. Einzig in Ländern wie denUSA, in denen das Transport- und Verkehrswesen jeder Staat unabhängig von den anderenreguliert (vgl. [PP05]), dürfte die Zahl der zu speichernden Zertifikate etwas größer ausfallen.

Sollte es dennoch notwendig werden, die Wurzelzertifikate eines anderen Kontinents zu be-antragen, so besteht die Möglichkeit, dass die „Heimat“-CA noch vorab die neuen Zertifikatebeschafft, cross-zertifiziert und dem Fahrzeug vertraulich zuschickt. Fernfahrern (LKW, Ku-rierdienste) stünden so in kurzer Zeit alle benötigten Zertifikate zur Verfügung, ohne die Mas-se ausufern zu lassen. Ist dies nicht möglich oder wechselt das Automobil längerfristig seinenStandort, kommt der Halter nicht umhin, es bei der zuständigen Behörde zu registrieren. Beidiesem Vorgang wird ihm dann das Wurzelzertifikat der „neuen“ CA zugewiesen.

Das Problem des Zugriffs auf das Fahrzeug ist auch hier gegeben allerdings in schwächererForm: Die Kraftfahrtsämter besitzen mit den Zulassungsstellen schon eine gut ausgebaute,geographisch verteilte Infrastruktur, die von den Bürgern (und ihren Fahrzeugen) leicht er-reicht und beim normalen Zulassungsprozess ohnehin aufgesucht werden muss. Im Rahmendieses Zulassungsprozesses wäre es ohne großen Mehraufwand möglich, Zugriff auf das Fahr-zeug zu bekommen.

4.5.5 Fazit

Tabelle 4.1 auf Seite 69 zeigt, dass sich die Kraftfahrtsämter am besten als Betreiber einerVANET-CA eignen. Einzig der Zugriff auf die Fahrzeuge zur Verteilung der Wurzelzertifikateund zur Erzeugung bzw. Verteilung des für die fahrzeugbezogene Identität benötigten kryp-tographischen Materials gestaltet sich problematisch. Auch das Vertrauen der Bürger in denSchutz ihrer Daten vor Missbrauch durch automatisierte Überwachung oder unzweckmäßigeVerwendung ist hier aufgrund bisheriger staatlicher Verhaltensweisen wohl eher nicht gegeben(vgl. Abschnitte 2.1.3 und 3.1.1).

Den Schutz der Privatsphäre würden unabhängige Datenschutzorganisationen wohl am bestengewährleisten, für den Zugriff auf die Fahrzeuge sind die Automobilhersteller in der bestenPosition. Erstrebenswert wäre ein Gesamtsystem, das die Vorteile dieser Instanzen vereint.

4.6 Datenübertragungsstandards für mobile Anwendungen 73

PAN < 10m802.15.1 (Bluetooth) < 1 Mbps

802.15.3 > 20 Mbps802.15.3a (UWB) < 480 Mbps802.15.4 (Zigbee) < 230 Kbps

LAN < 150m802.11 a/b/e/g: 11-54 Mbps

HyperLAN/2 < 54 Mbps802.11n (Vorschlag) > 100 Mbps

MAN < 5km802.16 a/d/e < 70 Mbps

LMDS < 38 Mbps802.11p (DSRC) < 27 Mbps

WAN < 15km802.20 (Vorschlag)

GSM, GPRS, CDMA, 2.5G, 3G10 Kbps - 2.4 Mbps

RAN < 100km802.22 (Vorschlag): 18 - 24 Mbps

Abbildung 4.3: Übersicht über existierende und zukünftige Funkverfahren nach [MCA06]

4.6 Datenübertragungsstandards für mobile Anwendungen

In diesem Abschnitt sollen die potentiell für VANETs geeigneten Mobilkommunikationspro-tokolle kurz auf ihre Eignung für VANETs hin geprüft werden. Ausgangspunkt ist eine sehrumfassende Übersicht über Funkverfahren aus [MCA06], die in Abbildung 4.3 zu sehen ist.

4.6.1 Anforderungen

Ein für VANETs geeignetes Mobilkommunikationsprotokoll sollte folgenden Anforderungengenügen:

• Ausgewogene Reichweite: In Funknetzen werden alle Nachrichten technisch via Broad-cast gesendet, auch wenn sie ausschließlich an einen Empfänger (Unicast) oder an eineausgewählte Gruppe (z.B. beim Geocasting) adressiert sind. Die Reichweite muss alsoeinerseits so groß sein, dass eine ausreichende Vorwarnzeit für die anderen VANET-Teilnehmer gegeben ist, andererseits darf sie aufgrund der Broadcast-Natur von Fun-knetzen aber auch nicht zu groß sein: Je größer die Reichweite, desto mehr Kollisionentreten auf, was vernünftige Kommunikation unmöglich machen kann. Abhilfe könn-ten hier adaptive Anpassungen der Sendeleistung oder gerichtete Antennen schaffen


a) Kollision durch hohe Sendereichweite

b) Anpassung der Sendeleistung

c) Einsatz von intelligenten Antennen

Reichweite A

Reichweite B

Überlappungs- bzw.Kollisionsbereich

BA

Nachricht von B

Nachricht von A

A

A

B

B

Abbildung 4.4: Kollisionsproblem durch zu hohe Reichweite und Lösungsvorschläge

(vgl. [Sch03b]). Beide Verfahren sind aber relativ kompliziert und technisch schwerumzusetzen, was mit den folgenden beiden Anforderungen kollidiert. Abbildung 4.4zeigt die Problematik und die vorgeschlagenen Lösungen. In [Lüb04] werden 1000mals sinnvolle Reichweite angesehen.

• Geringe Kosten: Die für die Funkübertragung benötigte Hardware soll möglichst kosten-günstig sein. Des Weiteren sollten für den Betrieb keine (nutzungsabhängigen) Kostenentstehen.

• Hohe Zuverlässigkeit: Das Funkverfahren muss eine kleine Bit-Fehlerrate9 (Bit ErrorRate, BER) haben und darf nicht anfällig für Störungen durch Rauschen oder Interfe-renzen sein.

• Ausreichende Übertragungskapazität: Im VANET werden unter Umständen sehr vieleNachrichten verschickt (z.B. bei einem Stau auf der Autobahn). Die Übertragungskapa-zität muss zumindest für die verkehrssicherheitskritischen Nachrichten ausreichen.

• Geringe Verzögerung: Aufgrund der kurzen zur Verfügung stehenden Kommunikations-zeiten und der zeitlichen Brisanz der verkehrssicherheitskritischen Nachrichten, müssendie Verzögerungen durch das Mobilkommunikationsprotokoll möglichst gering sein.

Die genannten Anforderungen implizieren, dass bei geeigneten Protokollen ein Ad-hoc-Betriebsmodus vorhanden sein muss. Zelluläre Systeme, die zwingend Basisstationen vor-aussetzen, sind nicht geeignet, da

9 [MXZ03] geht davon aus, dass eine BER von 10−6 für VANETs ausreichend ist.

4.6 Datenübertragungsstandards für mobile Anwendungen 75

• keine flächendeckende Verfügbarkeit von Basisstationen garantiert werden kann,

• hohe Kosten und meist zusätzliche Nutzungsgebühren anfallen, die durch die Kosten fürdie Installation und den Betrieb der Basisstationen sowie die Nutzung von lizenzpflich-tigen Frequenzen entstehen,

• Geocasting nicht bzw. nicht so gut möglich ist,

• mit höheren Verzögerungszeiten als im Ad-hoc-Betrieb zu rechnen ist, da immer erstdie Basisstation kontaktiert werden muss.

4.6.2 Protokolle

In [MCA06] wird eine Kategorisierung nach Reichweite vorgenommen. Es können daher sehrleicht alle Protokolle mit zu geringer oder zu hoher Reichweite ausgeschlossen werden. Üb-rig bleiben nur die Protokolle das MAN- und evtl. des WAN-Bereichs, konkret 802.16 a/d/e,LMDS, DSRC, GSM, GPRS, CDMS, 2.5G, 3G und 802.20.

WAN-Bereich Bei GSM, GPRS, CDMS, 2.5G und 3G handelt es sich um zelluläre Systeme,die nicht für VANETs geeignet sind (siehe oben). Zudem ist die verfügbare Übertragungska-pazität mit maximal 2,4 Mbps nicht ausreichend. Das 802.20 Protokoll ist zur Zeit noch nichtstandardisiert. Die bisherigen Vorschläge sehen zudem keinen Ad-hoc-Modus vor. Ein weite-rer Nachteil ist, dass die Hardware nicht kompatibel zu existierenden Systemen ist, was dieKosten für Entwicklung und Produktion (unnötig) erhöht.

MAN-Bereich LMDS ist der Vorgänger der 802.16 a/d/e (Wimax-)Familie und besitzt ähn-liche Merkmale wie seine Nachfolger-Protokolle. Die (Wimax-)Familie besitzt zur Zeit kei-nen Ad-hoc-Modus und die zu erreichenden Verzögerungszeiten sind nicht ausreichend fürdie VANET-Anforderungen (vgl. [Haa04]). Übrig bleibt DSRC, das auch von den führen-den Automobilherstellern und dem C2C-CC als Übertragungsprotokoll favorisiert wird (vgl.[CAM04]):

DSRC wurde von ASTM (American Society for Testing and Materials) und IEEE entwi-ckelt und soll im März 2009 ratifiziert werden [SZ07]. Der Standard basiert auf den WLAN-Standards 802.11a und 802.11g, wodurch Kompatibilität mit existierenden Strukturen gege-ben ist. Durch Frequenzwechsel in den Geräten ist der Zugang zu öffentlichen oder privatenHotspots möglich. Zusätzlich kann aufgrund existierender Standards kosteneffizient entwi-ckelt werden.

Bei einer Reichweite von 300-1000m wird eine Übertragungskapazität von 6-27 Mbps an-gestrebt, was sehr gut zu den Anforderungen passt. Die maximale Verzögerungszeit für dieDaten wird mit 100ms angesetzt, was zur Zeit kein anderes System erreicht (vgl. [Fra04],[YEY+04]). Zudem ist eine Priorisierung sicherheitsrelevanter Nachrichten durch einen Kon-trollkanal möglich.


AusgewogeneReichweite

GeringeKosten

HoheZuverlässigkeit

Ausr.Übertragungskapazität

GeringeVerzögerung

802.15.1 (Bluetooth) – ++ – – /

802.15.3a (UWB) – ++ / ++ /

802.15.4 (Zigbee) – ++ – – /

802.11 a/b/e/g/n – ++ – ++ /

HiperLAN/2 – + – ++ /

802.16 a/d/e (Wimax) ++ – ++ ++ –

802.11p (DSRC) ++ ++ ++ ++ ++

802.20 +(+) – / ++ –

GSM, GPRS, CDMA, 2.5G, 3G +(+) – ++ + –

nanoNET ++ + – + /

UTRA-TDD (Ad-Hoc) ++ – / + /

Tabelle 4.2: Übersicht über die untersuchten Mobilkommunikationsprotokolle

Das Protokoll verfügt über einen Ad-hoc-Modus und eine ausreichend kleine BER von 10−6.Die Störanfälligkeit gegenüber Interferenzen ist vergleichsweise gering, da DSRC in eigenenFrequenzbereichen arbeitet, die nicht von anderen Mobilkommunikationsprotokollen benutztwerden dürfen. Bereits 1999 wurde durch die FCC (Federal Communication Commission) ein75 MHz breites Frequenzband (5,850 - 5,924 GHz) für die USA reserviert. Für Europa undJapan ist der Frequenzbereich um 5,8 GHz vorgesehen (vgl. [Why05], [Tau06]), der im August2008 von der Europäischen Kommission für Europa reserviert wurde (siehe [Int08]).

Zwei nicht in [MCA06] enthaltene Protokolle mit angemessener Reichweite sind UTRA-TDD(Ad-Hoc) und nanoNET:

• UTRA-TDD (Ad-Hoc): Im Fleetnet-Projekt [URL08h] wurde ein Ad-hoc-Modus fürUTRA-TDD implementiert [Fra02] und getestet (siehe [BG03], [ERW+03], [ER-HL02]). Dieser scheiterte jedoch mangels Verfügbarkeit und der hohen Kosten fürdie benötigte Hardware (vgl. [PRe08]). Zudem war die Priorisierung von Nachrichtenschwierig umzusetzen.

• nanoNET erreicht geeignete Reichweiten bis zu 1000m und verfügt über einen Ad-hoc-Modus. Die Wahrscheinlichkeit von Interferenzen ist bei NanoNET allerdings sehrhoch, da im Bereich des ISM-Bandes um 2,4 GHz gesendet wird (vgl. [Hei04]). Dergrößte Nachteil ist die relativ hohe BER im Bereich von 10−3 (vgl. [Ziv05]).

4.7 Routing 77

Routing in MANETs

topologiebasiert positionsbasiert

proaktiv reaktiv hybrid

Abbildung 4.5: Routingansätze in MANETs nach [MWH01]

4.6.3 Fazit

Tabelle 4.2 fasst die Funkverfahren und ihre Eignung für VANETs noch einmal kurz zusam-men. Sie bezieht sich dabei auf die oben genannten Kriterien. Sind mehrere verwandte Pro-tokolle in einer Zeile, wird das am besten geeignete bewertet und fett gekennzeichnet. – stehtfür nicht erfüllt, + für erfüllt und ++ für sehr gut erfüllt. / bedeutet, dass dieses Kriteriumnicht bewertet werden kann10. Wie zu erwarten, ist – das speziell für VANETs entwickelte– DSRC am besten geeignet. DSRC wird daher für die weiteren Betrachtungen als VANETMobilkommunikationsprotokoll angenommen.

Auch dieses Protokoll kann natürlich nicht endgültig gegen den Einsatz von Störsendern ge-schützt werden. Wie schon in Abschnitt 3.1.3 angesprochen, bietet es einen gewissen techni-schen Schutz, wenn andere Mobilkommunikationsprotokolle als Alternative verfügbar sind.Dies erhöht allerdings die Kosten für das Gesamtsystem. Einen gewissen Schutz gegen Stör-sender bieten auch entsprechende Gesetze, die die Störung der für DSRC reservierten Fre-quenzen unter Strafe stellen.

4.7 Routing

Unter Routing versteht man den Prozess der Wegwahl einer Nachricht, die in einem Netzwerkvon einem Sender zu einem Empfänger übertragen werden soll. Dabei gibt es verschiedeneRoutingstrategien und Routingprotokolle, nach denen die Wahl des Weges bzw. des Pfadesgetroffen und die Nachricht übermittelt wird. Abbildung 4.5 zeigt eine Klassifikation der Rou-tingansätze in mobilen Ad-hoc-Netzen. Man unterscheidet dabei zwischen dem topologieba-sierten Routing und dem positionsbasierten Routing.

10Besonders zu den Verzögerungszeiten sind schwer verlässliche Informationen zu finden. Bei diesem Kriteriumwurde deswegen nur bei den wirklich geeigneten Verfahren genauer nachgeforscht.


4.7.1 Topologiebasiert

Topologiebasierte Routingverfahren nutzen zur Wegwahl die Informationen über die Nachbar-schaftsbeziehungen zwischen den einzelnen Knoten im Netz. Sie können weiter untergliedertwerden in proaktive, reaktive und hybride Protokolle [MWH01].

Proaktive topologiebasierte Verfahren, in [RT99] auch als „Table-Driven“ bezeichnet, versu-chen stets aktuelle und vollständige Informationen über alle imNetz verfügbaren Pfade in einerTabelle bereit zu halten. Ein Knoten weiß also zu jedem Zeitpunkt, über welchen Weg er eineNachricht schicken muss, um einen bestimmten Empfänger zu erreichen. Beispiele für proak-tive Protokolle sind das Destination-Sequenced Distance-Vector Routing (DSDV) [PB94] unddas Wireless Routing Protocol (WRP) [MGLA96]. Der Vorteil der proaktiven topologiebasier-ten Routingverfahren ist, dass Pfade bei Bedarf vorliegen und sofort genutzt werden können.Die stetige Aufrechterhaltung aktueller Routen schlägt allerdings mit einem enormen Kommu-nikationsaufwand zwischen den einzelnen Knoten zu Buche. Dies gilt insbesondere, je mehrKnoten am Netz teilnehmen und je höher die Mobilität der Knoten ist. Im schlimmsten Fall istder Kommunikationsoverhead des Routingverfahrens so hoch, dass es sogar zum Zusammen-bruch des Netzes kommen kann [MHF+02].

Reaktive topologiebasierte Verfahren, in [RT99] auch als „Source-Initiated“ bzw. „Demand-Driven“ bezeichnet, wollen den Kommunikationsoverhead des Routingverfahrens reduzieren,indem nur noch die Pfade vorgehalten werden, die gerade in Verwendung sind. Soll eine Nach-richt an einen Empfänger geschickt werden, der noch nicht bekannt ist, wird eine Route Disco-very gestartet, um eine entsprechende Route zu finden. Selbst der durch die Route Discoveryerzeugte Kommunikationsoverhead kann in hochdynamischen mobilen Ad-hoc-Netzen immernoch sehr hoch sein. Außerdem kann es passieren, dass eine Route noch vor dem ersten Sen-den der Nachricht bzw. während der Nachrichtenübertragung bereits wieder ungültig ist unddas Datenpaket verworfen werden muss [MHF+02]. Beispiele für reaktive topologiebasierteVerfahren sind AODV [PR99], DSR [JM96] und TORA [PC97].

Hybride topologiebasierte Verfahren versuchen die Vorteile der proaktiven und der reakti-ven Varianten zu vereinen. Sie verwenden für das lokale Routing (d.h. in der näheren Um-gebung) proaktive Verfahren und für das entfernte Routing (d.h. in der weiteren Umgebung)reaktive Verfahren. Dadurch lässt sich, verglichen mit reinen proaktiven Ansätzen, einerseitsder Kommunikationsaufwand zur Aufrechterhaltung der Routen reduzieren sowie andererseitseine bessere Skalierbarkeit erreichen [MWH01]. Ein Beispiel für ein hybrides Protokoll istZRP [HP01].

Allen topologiebasierten Verfahren gemein ist ihre eingeschränkte Skalierbarkeit, sowie derKommunikationsoverhead bei der Verwaltung von Routen in großen mobilen Ad-hoc-Netzen.Zudem können keine Nachrichten per Geocast an (unbekannte) Empfänger in einer bestimm-ten geographischen Region verschickt werden, was allerdings im VANET eine sehr wichtigeEigenschaft für die Zustellung von Warnungen und Alarmsignalen ist (vgl. Abschnitte 3.2.4und 3.2.5). Aus diesen Gründen eignen sich topologiebasierte Routingverfahren nicht für die

4.7 Routing 79

Anwendung in hochdynamischen VANETs, was die Entwicklung der positionsbasierten Rou-tingprotokolle zur Folge hatte (siehe [TC03], [MHF+02], [LHT+03]).

4.7.2 Positionsbasiert

Positionsbasierte Routingverfahren versuchen die Nachteile der topologiebasierten Variantenzu überwinden, indem sie zusätzliche Information wie die geographische Position der ein-zelnen Teilnehmer verwenden. Auch die Gebundenheit der Fahrzeuge an den Straßenver-lauf kann im VANET für eine geeignete Wahl des Pfades genutzt werden. Die grundsätzli-che Fähigkeit zum Geocasting besitzen alle positionsbasierten Routingverfahren automatisch(vgl. [MCA06]).

Um das Routing von Nachrichten zu einem bestimmten Empfänger zu ermöglichen, bestehtein positionsbasiertes Routingverfahren aus zwei wesentlichen Bestandteilen: dem Positions-dienst (Location Service) und der Weiterleitungsstrategie (Forwarding Strategy) [MWH01].Will ein Sender eine Nachricht an einen Empfänger übermitteln, so muss er zuerst dessengeographische Position in Erfahrung bringen. Um diese zu ermitteln, befragt er einen Posi-tionsdienst, der die Positionsinformationen der einzelnen Teilnehmer bereithält. Sobald diePosition des Empfängers ermittelt wurde, wird sie im Header des zu versendenden Datenpa-kets hinterlegt und die Nachricht wird an den Empfänger geschickt. Dabei erfolgt das Routinggemäß der Weiterleitungsstrategie meist nur auf Basis lokaler Entscheidungen des aktuell wei-terleitenden Knotens.

Um diese lokalenWeiterleitungsentscheidungen treffen zu können, verwenden die meisten po-sitionsbasierten Routingprotokolle das sog. Beaconing zur Bestimmung der Positionen ihrerNachbarn. Dabei übermittelt jeder Knoten in bestimmten zeitlichen Abständen seine aktuellePosition sowie evtl. weitere relevante Daten an alle Knoten in direkter Funkreichweite. Die sogewonnenen Informationen werden in der Location Table (auch Neighbor Table) gespeichert,auf die im Rahmen der Weiterleitung zurückgegriffen wird. Genau diese Informationen wer-den im VANET durch die ohnehin periodisch versendeten Telematik-Nachrichten (Beacons,siehe Abschnitt 3.2.3) zur Verfügung gestellt. Es fällt dafür im VANET also kein zusätzlicherKommunikationsoverhead an.

Abbildung 4.6 zeigt die in [MWH01] identifizierten Möglichkeiten, den Positionsdienst unddie Weiterleitungsstrategie auszugestalten. Eine genaue Erläuterung der Möglichkeiten undder zugehörigen Protokolle würde den Rahmen dieser Arbeit sprengen.

Einen guten Einstieg mit Vergleichen der Positionsdienste DREAM [BCSW98], Quorum Sys-tem [HL99, SV99], GLS [LJD+00,MJK+00] und Homezone [Sto99, GH00] sowie der Wei-terleitungsstrategien Greedy Forwarding [NK84,TK84,HL86,KSU99,KK00,SL01,MES04],DREAM [BCSW98], LAR [KV00a], Terminodes [BBC+01, BGL02] und Grid [LTLS00,LTS01] stellt [MWH01] dar. Ausführlichere Erklärungen der bekanntesten Protokolle sindbeispielsweise in [MCA06] zu finden.


Location Service

some-for-somesome-for-allall-for-someall-for-all

Forwarding Strategy

restricted directional floodinggreedy forwarding - next-hop selection - recovery strategyhierarchical approaches

Abbildung 4.6: Positionsbasiertes Routing nach [MWH01]

Die Geocasting-Protokolle LBM [KV98], Voronoi [SRL03], Mesh [BCT01], GeoGRID[LTLS00], URAD [MFE03], GeoNode [IN99] und GeoTORA [KV00b] werden in [Mai04]vorgestellt. Diese sind meist einfache Erweiterungen existierender positionsbasierter Routing-verfahren. Mit [SGM04] und [MLS05a] existieren auch zwei Protokolle, die Nachrichten füreinen bestimmten Zeitraum in einem vorgegebenen geographischen Gebiet „halten“ können.Dies ist z.B. nötig, um Glatteiswarnung für eine bestimmte Zeit aufrecht zu halten. Würdenur eine einfache Warnung an den nachfolgenden Verkehr abgesetzt, wären später folgendeFahrzeuge nicht mehr über die Gefahr informiert.

Zuletzt sei noch auf [HP04] und [FF06] hingewiesen, die mehrere sichere Routingverfah-ren (ARAN [SDL+02], SPAAR [CY02], SLSP [PH03], SAODV [Zap02], Ariadne [HPJ02],SEAD [HJP02] und SOLSR [CAJ+03]) untersuchen. [FF06] prüft diese sogar explizit auf ihreEignung für VANETs, geht aber leider nicht auf den Schutz der Privatsphäre ein.

4.7.3 Fazit

Aufgrund des vergleichsweise sehr geringen Overheads und der inhärenten Möglichkeit desGeocastings eignen sich positionsbasierte Routingverfahren hervorragend für VANETs, wassich auch mit den Aussagen in [LHT+03] deckt. Durch die Möglichkeit den Straßenverlaufin die Routingentscheidung mit einzubeziehen, können Sackgassen bei der Weiterleitung mitgroßer Wahrscheinlichkeit vermieden werden, indem die Nachrichten z.B. nicht über den kür-zesten sondern über den meistbefahrenen Weg geroutet werden (vgl. [TC03]). Topologieba-sierte Routingverfahren sind hingegen nicht gut geeignet.

Für den Schutz der Privatsphäre stellt der Positionsdienst, der zu jeder Zeit die aktuelle Po-sition der Teilnehmer kennen muss, eine Bedrohung dar. Da im Rahmen dieser Arbeit keinkonkretes Routingprotokoll vorgeschlagen werden kann, ist es auch nicht möglich konkreteMaßnahmen zum Schutz vor dieser Bedrohung zu entwickeln11. Das Beaconing und die di-

11In [FFBA07] werden einige allgemeine Vorschläge zur Absicherung gemacht: Ein Vorschlag ist es, den Po-sitionsdienst zuerst eine Autorisierung vom zu lokalisierenden Empfänger einholen zu lassen, bevor er eine

4.8 Intrusion Detection und Anreizsysteme 81

versen Forwarding-Strategien werden durch die später vorgeschlagene Sicherheitsinfrastruktur(siehe Kapitel 7) allerdings gut unterstützt und gesichert.

4.8 Intrusion Detection und Anreizsysteme

Intrusion Detection Systeme (IDS) sollen Angriffe auf das Netz erkennen und ggf. Maßnah-men einleiten, die die Sicherheit wieder herstellen. Wie in Abschnitt 3.1.3 schon angedeutet,wird durch IDS und Anreizsysteme auch die Verfügbarkeit des Netzes erhöht, da Anreize fürdie Benutzer geschaffen werden, sich korrekt und netzfördernd zu verhalten. Zeigt ein Teilneh-mer fehlerhaftes, egoistisches oder böswilliges Verhalten (kurz Fehlverhalten, siehe für einegenauere Erläuterung [Kar03]), kann dieses entdeckt und geahndet werden.

Im Folgenden werden zuerst Optionen aufgezeigt, wie mit Fehlverhalten umgegangen werdenkann. Danach werden in Abschnitt 4.8.2 grundlegende Möglichkeiten zur Entdeckung vonAngriffen bzw. Fehlverhalten kurz vorgestellt. Bevor in Abschnitt 4.8.4 die Erkenntnisse kurzzusammengefasst werden, sind in Abschnitt 4.8.3 einige Informationen zu Anreizsystemen zufinden.

4.8.1 Reaktionsmöglichkeiten

Wie in Abschnitt 4.2 erläutert, ist eine eindeutige Identifikation der Teilnehmer notwendig,um Reaktionen auf Fehlverhalten durchsetzen zu können. Wenn eine anonyme Teilnahmeim VANET möglich wäre, würde langfristig jede Maßnahme ins Leere laufen [Kar03]. Einsich fehlverhaltender Teilnehmer müsste sich nur eine neue Identität geben und könnte ohneVorbelastung wieder fehlerhaftes Verhalten zeigen. Im Folgenden werden kurz verschiedeneReaktionsmöglichkeiten diskutiert ohne auf deren konkrete Umsetzung einzugehen:

• Keine Reaktion: Erkanntes Fehlverhalten könnte einfach ignoriert werden. Man begnügtsich damit, das Fehlverhalten erkannt zu haben ohne irgend eine Konsequenz daraus zuziehen. Dies ist die am einfachsten umzusetzende Möglichkeit, die aber entscheidendeNachteile hat: Einerseits können böswillige Teilnehmer weiter ungehindert das Netzstören und andererseits haben Teilnehmer, die nur aufgrund eines Defekts des FahrzeugsFehlverhalten zeigen, keine Möglichkeit davon zu erfahren. Entscheidet man sich fürdiese Möglichkeit, braucht man eigentlich auch kein IDS.

• Information an den Teilnehmer: Wird Fehlverhalten erkannt, könnte man den Teilneh-mer darauf hinweisen. Ist das Fehlverhalten unabsichtlich, z.B. durch einen Defekt desFahrzeugs entstanden, kann der Teilnehmer darauf reagieren und beispielsweise seinFahrzeug überprüfen und reparieren lassen. Ein Teilnehmer sollte daher – auch wenn

Positionsanfrage beantwortet. Ein weiterer Vorschlag wäre, nach einem Pseudonymwechsel noch Nachrichtenzu akzeptieren, die an das alte Pseudonym geschickt wurden und dem jeweiligen Sender das neue Pseudonymund ggf. die neue Position gesichert durch Ende-zu-Ende-Verschlüsselung zukommen zu lassen.


weitere Reaktionen folgen – über sein Fehlverhalten informiert werden. Nachteilig ist,dass diese Information auch einem Angreifer bei der Analyse und Verfeinerung seinesAngriffs helfen könnte.

• Lokal begrenzter Ausschluss: Eine weiterreichende Möglichkeit ist ein zeitlich und geo-graphisch begrenzter Ausschluss des sich fehlverhaltenden Teilnehmers. Hier ergebensich folgende Ausprägungen:

– Nichtbeachtung der Nachrichten: Die Nachrichten des betreffenden Teilnehmerswerden ignoriert, d.h. die umgebenden Fahrzeuge beziehen Beacons und Warnun-gen des Teilnehmers nicht in die Konstruktion der globalen Verkehrslage mit ein.Hier ist zu bedenken, dass ein Teilnehmer, der sich lediglich egoistisch verhält,durchaus wichtige und richtige Daten zum Verkehrsgeschehen liefern kann. Selbstwenn ein Teilnehmer für das (böswillige) Versenden falscher Informationen be-kannt ist, könnte er (z.B. wenn er selbst einen Unfall hatte) lebensrettende Informa-tionen verschicken. Das Ignorieren von Nachrichten, die für die Verkehrssicherheitrelevant sind, ist aus diesem Blickwinkel daher nicht zu empfehlen.

– Meiden des Teilnehmers: Bei der Konstruktion der Route bzw. bei der Weiterlei-tung von Nachrichten können Teilnehmer gemieden werden, die Fehlverhalten zei-gen. Dies kann den Schaden mindern, den böswillige Knoten z.B. durch Verwerfenvon Nachrichten anrichten können. Egoistischen Knoten würde man damit aller-dings einen Gefallen tun. Sie würden in Zukunft nicht mehr mit der Weiterleitungvon Nachrichten belästigt werden, ohne dass ihnen dadurch Nachteile entstünden(vgl. [Kar03]).

– Verwerfen der Nachrichten: Soll auch dem Teilnehmer, der Fehlverhalten zeigt,ein Nachteil entstehen, könnte man alle Nachrichten von und an diesen Teilnehmereinfach verwerfen. Er kann dann keine Kommunikation über mehrere Hops mehraufbauen und beispielsweise keine Komfort-Dienste mehr nutzen. Für egoistischeKnoten kann dies durchaus einen Anreiz schaffen, sich korrekt zu verhalten. Bös-willige Knoten werden sich dadurch zwar nicht abhalten lassen, Fehlverhalten zuzeigen, allerdings würde deren Reichweite deutlich begrenzt. Auch hier ist aberzu bedenken, dass potentiell für die Verkehrssicherheit wichtige Nachrichten nichteinfach verworfen werden sollten.

• Globaler Ausschluss: Eine weitere Reaktion auf Fehlverhalten ist der komplette Aus-schluss eines Teilnehmers aus dem VANET. Dies kann beispielsweise dadurch gesche-hen, dass die CA seine VANET-Identität zurückruft oder nicht weiter verlängert. DerTeilnehmer kann dann keine authentifizierten Nachrichten mehr versenden, wodurchseine Nachrichten von den anderen Teilnehmern ignoriert und nicht mehr weitergelei-tet werden. Auch hier ist zu bedenken, dass der Knoten dann keine Nachrichten mehrversenden kann, die für die Verkehrssicherheit relevant sind.

• Strafrechtliche Verfolgung: Unter Umständen kann es sinnvoll sein, über den bloßenAusschluss eines Knotens hinauszugehen. Strafrechtliche Konsequenzen wären denk-


bar, wenn durch Einspeisung falscher Informationen z.B. Unfälle provoziert werden.Sieht man eine solche Reaktionsmöglichkeit vor, sollte im Sinne der mehrseitigen Si-cherheit aber kein Missbrauch in Form von automatisierter Strafverfolgung bei margi-nalem Fehlverhalten möglich sein.

4.8.2 Erkennung von Fehlverhalten und Reputationssysteme

Es gibt viele Verfahren, die sich mit der Erkennung und der Reaktion auf Fehlverhalten speziellin MANETs befassen. Eine gute Übersicht zu IDS in MANETs ist beispielsweise in [AW07]zu finden. In [STL+08] findet sich eine gute Übersicht über die Möglichkeiten, aufbauend aufdie Erkennung von Fehlverhalten Vertrauen mit Hilfe von Reputationssystemen aufzubauenund Reaktionen durchzusetzen.

Technisches Fehlverhalten

Die in MANETs eingesetzten IDS und Reputationssysteme haben meist nur das Ziel, techni-sches Fehlverhalten zu entdecken und darauf zu reagieren. Unter technischem Fehlverhaltenwird dabei Verhalten wie das Versenden ungültiger Nachrichten, das Verwerfen oder Verän-dern von Nachrichten oder die Störung des Routingprotokolls verstanden. Die Systeme be-schäftigen sich normalerweise nicht mit der Erkennung fehlerhafter Anwendungsdaten, da dieAnwendungen dazu nicht genau genug spezifiziert sind.

Das ursprünglich für das Routingprotokoll DSR [JM96] entwickelte Watchdog-Pathrater-Verfahren [MGLB00] wird im Folgenden exemplarisch näher betrachtet, da nach diesem oderähnlichen Prinzipien auch viele andere Erkennungssysteme für technisches Fehlverhalten wieCONFIDANT [BB02] und dessen Nachfolger RRS [BB04], Mobiles IDS nach Zhang/Lee[ZL00], [ZLH03], CORE [MM02], Snooping Protocol Extensions [PUPJ04], SAM [Kar03],RFSN [GS04] oder DRBTS [STW06] arbeiten (vgl. [STL+08]).

Watchdog: Ein Knoten A in Reichweite von Knoten B hört im Promiscuous Mode12 alleausgehenden Datenpakete von Bmit und wird als Watchdog bezeichnet. A kann so überprüfen,ob B die Pakete, die dieser zumWeiterleiten empfangen hat, auch wirklich unverändert an dennächsten Knoten in der Kette weiterzuleiten versucht (vgl. Abbildung 4.7 a)). Sollte das nichtder Fall sein, kann er den Absender S des Datenpaketes darüber informieren.

Im Folgenden werden die auch schon in [MGLB00] erkannten Probleme genannt, die beimWatchdog-Ansatz auftreten können:

• Wenn bei A eine Kollision in dem Augenblick eintritt, in dem er das Datenpaket von Bempfangen würde, so ist für A nicht klar ersichtlich, ob B sein Paket weitergeleitet hatoder nicht (vgl. Abbildung 4.7 b)).

12PromiscuousMode bezeichnet eine Betriebsart eines Netzwerkadapters, in der alle statt nur die an ihn gerichtetenPakete mitgelesen werden.


a) S A DCB

b) S A DCB

KollisionNachricht Abgehörte Nachricht

S A DCBc)

Abbildung 4.7: Funktionsweise des Watchdogs A und Probleme bei Kollisionen nach[MGLB00]

• Ebenso kann beiC eine Kollision aufgetreten sein und A das von B gesendete Paket kor-rekt empfangen haben. Wenn nun B das Paket anC nicht erneut sendet, geht A fälschlichdavon aus, dassC das Paket erhalten hat (vgl. Abbildung 4.7 c)).

• B könnte seine Signalstärke so modifizieren, dass das Paket von A zwar empfangen wird,aberC niemals erreicht.

• Da es, wie oben beschrieben, durch Kollisionen zu Fehleinschätzungen kommen kann,wird A mit einer „Anschuldigung“ genannten Information an S warten, bis eine gewisseSchwelle erreicht ist. Ein bösartiger Teilnehmer kann das bewusst ausnutzen und nurpartiell Pakete verwerfen, so dass er unter der Schwelle bleibt und nicht mit einer An-schuldigung zu rechnen hat.

• Ein Knoten kann einen anderen Knoten fälschlich beschuldigen, Datenpakete nicht wei-terzuleiten.

• Wenn sich mehrere bösartige Teilnehmer zusammen finden, können sie z.B. durch denmassenhaften Versand falscher Anschuldigungen Angriffe durchführen, die nur sehrschwer zu entdecken sind. In [MGLB00] wird daher davon ausgegangen, dass Knotenimmer alleine handeln.

• Ein weiteres für VANETs relevantes Problem wird in [Kar03] genannt: Aufgrund vonhoher Mobilität könnte A sich ausserhalb der Sendereichweite von B befinden, bevorer die weitergeleitete Nachricht von B empfangen hat. A würde dann fälschlich davonausgehen, dass B das Paket nicht weitergeleitet hat.

Pathrater: Jeder Knoten im Netz ist gleichzeitig auch ein sog. Pathrater. Als solcher er-stellt und speichert er eine Bewertung (Reputation) über jeden Knoten, den er im Netz kennt.Wenn er als Watchdog einen sich fehlverhaltenden Knoten identifiziert oder eine Anschuldi-gung von einem anderen Watchdog eintrifft, wird der betreffende Knoten abgewertet. Beim


Routing werden Pfade, auf denen sich Knoten mit schlechter Bewertung befinden, dann nurnoch nachrangig ausgewählt, d.h. es findet ein lokal begrenzter Ausschluss statt, bei dem Kno-ten mit schlechter Reputation für die Weiterleitung von Nachrichten gemieden werden. Da eswie oben dargestellt sehr leicht zu Fehlerkennungen (false-positives) und falschen Anschuldi-gungen kommen kann, schlagen die Autoren in [MGLB00] vor, dass sich die Bewertung übereinen Knoten im Laufe der Zeit langsam wieder bessern soll.

Die Hauptunterschiede zwischen den oben genannten Ansätzen bestehen in der Verwaltungder Reputation der einzelnen Teilnehmer und den konkret vorgeschlagenen Reaktionen undMechanismen zur Verteilung der Bewertungen. In einigen Vorschlägen wie z.B. [PUPJ04]und [Kar03] wird auch der Watchdog verbessert, allerdings ohne die genannten Problemeendgültig beseitigen zu können.

Fehlverhalten auf der Anwendungsebene

Die in den Beacons enthaltenen (redundanten) Informationen erlauben es im VANET aller-dings auch Fehlverhalten und Angriffe auf Anwendungsebene erkennen zu können, indem dieempfangenen Daten mit den Daten der fahrzeugeigenen Sensoren und den Daten aus anderenNachrichten validiert werden. Wie diese Datenvalidierung erfolgen könnte, wird in [GGS04]näher betrachtet.

Die Autoren schlagen folgendes Vorgehen vor, um fehlerhafte Daten in einem VANET entde-cken zu können:

• Jeder Knoten verfügt über ein Modell des VANETs, das alle Informationen enthält, dieein Knoten über das VANET hat. Bestimmte Konstellationen können dabei ausgeschlos-sen werden (z.B. können sich zwei Fahrzeuge nicht zur selben Zeit am selben Ort befin-den).

• Jeder Knoten kann sein Modell um eigene Beobachtungen erweitern. Den eigenen Be-obachtungen kann ein Knoten uneingeschränkt vertrauen.

• Empfängt ein Knoten Daten von einem anderen Knoten, so kann er die Daten mit seinemModell des VANETs abgleichen. Passen die Daten (mit hoher Wahrscheinlichkeit) insein Modell, akzeptiert er die Information als wahr.

Für den Umgang mit Unstimmigkeiten wurde von den Autoren die Heuristik Adversarial Par-simony entwickelt. Angriffe, bei denen wenige Knoten zusammenarbeiten müssen, werdendabei als wahrscheinlicher betrachtet als Angriffe bei denen sich viele Knoten absprechenmüssen. Zudem wird ein Knoten immer versuchen, eine konsistente Datenbasis zu erreichen.Er wird letztendlich die Daten als fehlerhaft betrachten, die von einer Minderheit der Knotengemeldet werden.

Je dichter das Netz ist, desto einfacher lassen sich inkonsistente Daten entdecken. Dies liegtdaran, dass der Erfolg eines Angriffs von speziellen Konstellationen im Netz abhängt, die in


O

A1

A2

A3

A4

A5

a) b)

OA1

A2

A3

A4

A5

Abbildung 4.8: Gelungener und fehlgeschlagener Angriff kooperierender Angreifer nach[GGS04]

einem dichten mobilen Netz nur sehr schwer für einen signifikanten Zeitraum aufrechterhaltenwerden können. Diesen Aspekt soll folgendes in Abbildung 4.8 dargestelltes Beispiel verdeut-lichen: Die konspirierenden schwarzen Angreifer Ax wollen falsche Informationen verbreiten.Im Fall a) würde es den Angreifern gelingen, das Opfer O von den falschen Daten zu überzeu-gen. Im Fall b) würde O die Informationen als falsch erkennen.

Aufbauend auf diesen Ansatz wurden weitere Vorschläge zur Datenvalidierung in VANETsgemacht. Vier vergleichsweise einfache Strategien zur Erkennung von fehlerhaften Informa-tionen werden in [ODS07] vorgeschlagen und untersucht (konkret: Neuste Nachricht gewinnt,Mehrheit gewinnt, Mehrheit der neusten x Nachrichten gewinnt, Mehrheit der neusten x Nach-richten mit Schwellwert gewinnt). Laut den Autoren ist die letzte Strategie (Mehrheit der neus-ten x Nachrichten mit Schwellwert gewinnt) vielversprechend, wenn genügend Nachrichtenvorhanden sind, um den Schwellwert zu überschreiten. Warnungen, die in nicht ausreichenderZahl vorhanden sind, werden immer abgelehnt.

In [DFM05], [RPA+07] und [RPGH07] wird mit Wahrscheinlichkeiten gearbeitet, um fehler-hafte Informationen zu erkennen. Bemerkenswert an dem Vorschlag in [RPGH07] ist, dasseine gewichtete Bewertung stattfindet. Dabei wird jedem Fahrzeug eine grundsätzliche Ver-trauenswürdigkeit zugesprochen, die z.B. davon abhängt, wie oft die Fahrzeuge gewartet wer-den, wie viel sie unterwegs sind und wem sie gehören. Nachrichten von Fahrzeugen des öf-fentlichen Nahverkehrs oder Einsatzfahrzeugen werden stärker gewichtet als Nachrichten vonnormalen Privat-KFZ. Auch die geographische Nähe zumOrt des Ereignisses und die ereignis-bezogene Vertrauenswürdigkeit des sendenden Fahrzeugs wird in die Gewichtung einbezogen.Einem Polizeifahrzeug wird z.B. bei Unfall- oder Stauwarnungen eine sehr hohe ereignisbe-


zogene Vertrauenswürdigkeit zugeteilt, da die Polizei im Normalfall bei solchen Situationenpräsent ist.

Kurzbewertung

An dieser Stelle kann nur eine Kurzbewertung vorgenommen werden, da aus Platzgründen kei-ne umfassende Vorstellung und Untersuchung der existierenden Systeme möglich ist. Grund-sätzlich erscheint ein IDS aufbauend auf einen Watchdog als unterstützende Maßnahme sehrsinnvoll, wenngleich die Gefahr von Fehleinschätzungen besteht. Ein darauf aufbauendes ver-teiltes Vertrauens- und Reputationssystem, das ggf. Reaktionen einleitet, erscheint aus folgen-den Gründen hingegen weniger geeignet:

• Für den Austausch der Bewertungen wird je nach konkreter Ausgestaltung des Aus-tauschmechanismus viel bis sehr viel Übertragungskapazität benötigt. Viele Ansätzegehen beispielsweise davon aus, dass alle Teilnehmer von allen anderen TeilnehmernNachrichten empfangen und Bewertungen über alle Teilnehmer speichern. Ein solchesVorgehen wäre aber im VANET schon allein aufgrund des damit verbundenen sehr ho-hen Speicherbedarfs in den Knoten nicht möglich. Wird allerdings nur für schon be-kannte Teilnehmer eine Reputation gespeichert, könnten Angreifer beispielsweise nacheinem lokalen Ausschluss einfach in ein anderes Teilnetz wechseln und dort wiederSchaden anrichten.

• Aufgrund der hohen Mobilität wird man oft Nachrichten und Warnungen von Teilneh-mern empfangen und einschätzen müssen, mit denen man vorher noch keinen Kontakthatte. Zudemwird sich der Kontakt in vielen Fällen auf einen kurzen Zeitraum beschrän-ken. Es ist also fraglich, ob ein lokal arbeitendes Reputationssystem genügend Informa-tionen über einen Teilnehmer sammeln kann, um diesen zuverlässig zu bewerten. Durchdie angesprochene potentiell hohe Zahl (absichtlich oder unabsichtlich) falscher An-schuldigungen wird das Problem der fehlenden Bewertungsbasis noch verstärkt.

• Lokale Ausschlüsse sind nicht im ganzen Netz bekannt, der sich fehlverhaltende Teil-nehmer müsste nur das geographische Gebiet wechseln, um das Netz weiter stören zukönnen. Zudem ist eine angemessene netzinterne Reaktion auf Fehlverhalten schwer zufinden, da der betreffende Teilnehmer ja durchaus richtige und wertvolle Informationenzur Erhöhung der Verkehrssicherheit liefern könnte.

• Werden zum Schutz der Privatsphäre Pseudonyme verwendet oder können die Teilneh-mer beliebig Pseudonyme bzw. Identitäten generieren, muss die Bewertung für jedesPseudonym einzeln erstellt werden. Ein Angreifer, der unter einem bestimmten Pseud-onym ausgeschlossen wird, könnte einfach ein neues Pseudonym verwenden und denAusschluss so umgehen.

Eine bessere Strategie könnte sein, nur von speziellen Knoten (z.B. stationäre Infrastruk-tur, Polizeifahrzeuge etc.) eine Erkennung von Fehlverhalten durchführen zu lassen, die die-ses Fehlverhalten dann (zusammen mit entsprechenden Beweisen) an eine vertrauenswürdige


Zentralstelle melden. Diese kann dann nach Prüfung der Sachverhalte und weiteren festge-legten Kriterien z.B. zur Art und Anzahl der Anschuldigungen entsprechende Maßnahmeneinleiten, die im ganzen VANET durchgesetzt werden können. Ist dieser Stelle auch bekannt,welche Pseudonyme einem bestimmten Teilnehmer gehören, kann sie Fehlverhalten unter al-len Pseudonymen zusammenführen und die Reaktionen auf das Fehlverhalten für alle Pseud-onyme des Teilnehmers durchsetzen.

Das oben angesprochene Problem der Fehleinschätzung durch die hohe Mobilität der Fahrzeu-ge kann gemindert werden, wenn die Watchdogs die Informationen zu Position, Geschwindig-keit und Richtung eines beobachteten Teilnehmers aus dessen Beacons auswerten und damitentscheiden, ob sich dieser noch in Reichweite befindet. Der Einsatz spezieller Watchdogs unddie zentrale Auswertung schränken zudem die Angriffsmöglichkeiten durch falsche Anschul-digungen ein.

Sehr gut als unterstützende Maßnahme geeignet erscheint die Erkennung von Fehlverhaltenauf der Anwendungsebene durch Datenvalidierung, die sich auf Informationen aus empfan-genen Nachrichten und eigene Sensordaten stützt. Es entsteht kein zusätzlicher Datenverkehrund Angreifern wird es erschwert, unwahre Situationen im VANET zu simulieren. Es ist aller-dings festzuhalten, dass es für diese Art der Datenvalidierung von entscheidender Bedeutungist, dass ein Teilnehmer andere Knoten voneinander unterscheiden kann. Es darf folglich kei-nem Teilnehmer möglich sein, weitere fiktive Knoten zu erzeugen13, da er sonst leicht eineMehrheit erzeugen könnte, der bei der Validierung vertraut wird.

Dies führt zu zwei gravierenden Nachteilen der Datenvalidierungsansätze:

• Wird die Privatsphäre der Teilnehmer z.B. durch den Einsatz von Pseudonymen ge-schützt, kann die Unterscheidung der Teilnehmer bei der Datenvalidierung nicht mehrzuverlässig durchgeführt werden. Kann der Wechsel der Pseudonyme zudem von denTeilnehmern autonom durchgeführt werden, könnten Angreifer z.B. durch den gleich-zeitigen Einsatz mehrerer Pseudonyme oder einen extrem schnellen Pseudonymwechselden Entscheidungsprozess negativ beeinflussen.

• Die Erkennung funktioniert nur bei ausreichend hoher Verkehrs- bzw. Nachrichtendich-te zuverlässig. Zudem gibt es Ereignisse, die nicht (oder nicht sofort nach Eintritt) vali-diert werden können: Bleibt beispielsweise ein Fahrzeug aufgrund eines Defekts liegenund blockiert die Fahrbahn, kann kein anderes Fahrzeug diese Information bestätigen.Erst wenn sich aufgrund der blockierten Fahrbahn z.B. ein Stau bildet, berichten meh-rere Teilnehmer von dem Ereignis, wodurch es validiert werden kann.

Da im VANET die Integrität und Authentizität der Nachrichten zuverlässig und schnell geprüftwerden muss (siehe Abschnitt 3.2), können die genannten Ansätze aufgrund der beschriebenenProbleme die eigentlichen Sicherungsmaßnahmen nicht ersetzen. Sie stellen vielmehr eine Artzweite Verteidigungslinie dar, die bei unklaren Situationen Entscheidungshilfe leisten kann.

13Dieser als Sybil Attack bekannte Angriff und einige Lösungsvorschläge werden in [Dou02] beschrieben.


4.8.3 Anreizsysteme

Neben solchen indirekt durch Bestrafung (z.B. Verlust von Reputation bzw. Glaubwürdigkeit,Ausschluss aus dem Netz, Strafverfolgung etc.) wirkenden Systemen, gibt es auch Anreizsys-teme wie Nuglets [BH01], [BH03], Sprite [ZYC02] oder APE [BFG+01], die durch Beloh-nung korrektes und netzförderndes Verhalten erreichen möchten. Solche Anreizmechanismenund deren technische Umsetzung werden beispielsweise in [And03] und [Ref05] untersucht.

Nuglets

Bei diesem Ansatz werden Nuglets als virtuelle Währung verwendet, um einen Anreiz zumWeiterleiten von Nachrichten zu schaffen. Erzeugt ein Knoten Datenverkehr, muss er dafürNuglets ausgeben, die er sich verdienen kann, indem er Daten für andere Knoten weiterlei-tet. Der Ansatz kommt dabei ohne zentrale Instanzen aus, da die Verwaltung des Nuglet-Guthabens in manipulationssicherer Hardware stattfindet. Zur Abrechnung werden zwei Mo-delle vorgeschlagen: Beim Packet Purse Model (PPM) trägt der Absender eines Pakets dieKosten. Er muss das Paket mit einem so hohen Guthaben versehen, dass dieses für den Trans-port bis zum Ziel ausreicht. Beim Packet Trade Model (PTM) wird ein Paket von Knoten zuKnoten weiterverkauft. Am Ende muss der Empfänger eines Pakets die Kosten tragen.

Jedes Modell hat dabei spezifische Nachteile: Ein großes Problem bei PTM ist, dass ein An-greifer einem Knoten alle Nuglets entziehen kann, indem er ihm viele (ungewollte) Paketezusendet. Bei PPM können Knoten in Randgebieten oder weniger dichten Netzen evtl. nichtgenügend Nuglets verdienen, um eigene Daten versenden zu können [Kar03]. Zudem kannschwer abgeschätzt werden, wie viele Nuglets einem Paket mitgegeben werden müssen, damites bis zum Ziel befördert werden kann. Auch die in [BH01] beschriebene Kombination beiderModelle kann diese wesentlichen Nachteile nicht beseitigen.

Sprite

Dieses System ist dem Nuglets Ansatz sehr ähnlich. Auch hier werden Knoten für das Weiter-leiten von Nachrichten mit einer virtuellen Währung belohnt. Die Kosten für den Verkehr trägtdabei immer der Sender. Jeder Teilnehmer verfügt über ein Zertifikat mit dem die Nachrich-ten signiert werden. Die manipulationssichere Hardware zur Verwaltung des Guthabens wirddurch einen gelegentlichen Zugriff auf eine übergeordnete Instanz, den Credit Clearance Ser-vice (CCS) ersetzt. Dieser ist dafür verantwortlich, dass die Bezahlung für übermittelte Paketekorrekt erfolgt. Es ist sogar vorgesehen, dass man in gewissem Umfang virtuelle Währung mitechtem Geld erwerben kann.

In [And03] wird noch auf die Ad-Hoc Participation Economy (APE) verwiesen, die Spritesehr ähnlich ist, allerdings eine Verhandlungsphase zulässt und die Umwandlung von virtuellerWährung in echtes Geld erleichtern will.


Kurzbewertung

Die beschriebenen Anreizsysteme können potentiell dazu beitragen, dass sich die Teilnehmerkooperativ verhalten. Vor allem bei den Komfort-Diensten erscheint es sinnvoll, für den bei derNutzung erzeugten Datenverkehr zu bezahlen. In VANETs stellt auch der gelegentliche Zugriffauf die übergeordnete Instanz, wie er bei Sprite vorausgesetzt wird, kein großes Problem dar.Mautstationen oder Tankstellen könnten zu regelmäßigen Kontaktpunkten ausgebaut werden.

Bei den anderen Anwendungen wird der Datenverkehr allerdings primär zum Nutzen der an-deren Teilnehmer erzeugt, die z.B. vor gefährlichen Situationen gewarnt werden sollen. Hierist es eher kontraproduktiv, für das Senden von Daten bezahlen zu müssen, da der sendendeTeilnehmer meist keinen Zusatznutzen aus dem Versand erzielt und somit auch nicht bereitsein wird, virtuelle Währung dafür auszugeben. Zudem könnte der Fall eintreten, dass einewichtige Warnung nicht versendet werden kann, da der betreffende Teilnehmer nicht über ge-nügend Währung für den Versand verfügt.

Eine Lösungsmöglichkeit für diese Probleme wäre, das System umzudrehen und die Teilneh-mer für das Senden von Verkehrsinformationen zu bezahlen. Dann könnten Angreifer aberdurch das Fluten des Netzes mit Verkehrsinformationen ein beliebiges Guthaben generieren.Ist ein Wechsel in echte Währung möglich, könnten sie sich beispielsweise sogar durch DoS-Angriffe bereichern. Auch diese Variante ist also abzulehnen.

Ein weiteres Problem dieser Anreizsysteme ist, dass lediglich egoistisches Verhalten einge-dämmt werden kann. Böswillige Angreifer werden sich in der Regel nicht von Angriffen ab-halten lassen, nur weil dadurch (virtuelle) Kosten für den Versand von Nachrichten entstehen.Ein Erkennen oder Verhindern von böswilligem Verhalten ist durch diese Systeme nicht mög-lich. Insgesamt erscheinen solche Anreizsysteme daher für das VANET wenig geeignet.

4.8.4 Fazit

Anreizsysteme und der Aufbau von Vertrauen über Reputationssysteme erscheinen aufgrundder oben genannten Gründe (hoher Bedarf an Übertragungs- und Speicherkapazität, viele Feh-lerkennungen, Probleme bei Verwendung von Pseudonymen etc.) für einen Einsatz im VANETwenig geeignet. Eine Kombination aus Erkennung von technischem Fehlverhalten und Fehl-verhalten auf der Anwendungsebene, wie sie auch in [LHSW04] vorgeschlagen wird, ist alsunterstützende Maßnahme zur Erkennung von Einbrüchen in das eigentliche Sicherungssys-tem und zur Entscheidungshilfe bei unklaren Situationen allerdings durchaus zu begrüßen. DieVorschläge zur zentralisierten Erkennung und die Aufstellung möglicher Reaktionen könnenals Ausgangspunkt für weitere Forschung dienen. Konkrete Fragestellungen wären beispiels-weise, wie die Erkennung am besten umgesetzt werden kann und was angemessene Reaktio-nen auf erkanntes Fehlverhalten sind.

4.9 Annahmen 91

4.9 Annahmen

In einem VANET werden drahtlos Nachrichten ausgetauscht, was diverse Anwendungen er-möglicht. Eine Kategorisierung und Beschreibung möglicher Anwendungen wurde in Ab-schnitt 3.2 vorgenommen. Hier soll daher nur die dabei verwendete Technik kurz beschriebenwerden. Des Weiteren werden einige Annahmen getroffen.

• In dieser Arbeit wird Sicherheit im Sinne von Security verstanden (siehe auch Abschnitt3.1). Der Bereich Safety wird nicht explizit betrachtet.

• Die Schutzmechanismen sollen möglichst unabhängig vom konkreten Übertragungspro-tokoll sein. Um die für die Bewertung nötigen Rahmenbedingungen vorzugeben, wirdfür die Funkverbindungen im VANET DSRC bzw. der dafür geschaffene Standard IEEE802.11p angenommen. Diese Wahl basiert auf den Vorüberlegungen in Abschnitt 4.6.

• Unter Automobilen bzw. Fahrzeugen werden in dieser Arbeit PKWs, LKWs und Busseverstanden. Zweiräder und andere Verkehrsteilnehmer sind von der Betrachtung aus-geschlossen, da dies unnötige Einschränkungen bezüglich der einsetzbaren Hardwarenach sich ziehen würde. Es wird angenommen, dass jedes Fahrzeug mit den folgendenKomponenten ausgestattet ist:

– Ein Transmitter für den omnidirektionalen Empfang und Versand von Daten imVANET.

– Eine Rechnereinheit, die die Verarbeitung und Auswertung der Nachrichten desVANETs und der Daten der internen Fahrzeugsensoren übernimmt. Dazu gehört,soweit nicht anders angegeben, auch das Empfangen und der Versand von Nach-richten, das Routing im VANET (siehe Abschnitt 4.7), die Priorisierung der Nach-richten, die Berechnung kryptographischer Operationen zur Sicherung der Nach-richten und ggf. die Aufbereitung der Informationen für den Fahrer.

– Für viele Lösungen wird eine vertrauenswürdige, physikalisch abgesicherte Hard-ware (TRH) vorausgesetzt, die Aufgaben der Rechnereinheit ganz oder teilweiseübernimmt. Jede Lösung, die TRH voraussetzt, weist gesondert darauf hin und eswird dann folglich davon ausgegangen, dass keine Manipulationen an der TRHmöglich sind. Weitere Überlegungen zu manipulationssicherer Hardware wurdenbereits in Abschnitt 4.3 angestellt. Alternativ oder zusätzlich zu einer TRH kannunter Umständen auch ein Smartcard-Leser integriert sein. Die Smartcard stelltdann ebenfalls physikalisch abgesicherte Hardware dar.

– Ein System zur Bestimmung der aktuellen Position und Zeit. Möglichkeiten zursicheren Positions- und Zeitbestimmung werden in Abschnitt 5.2 betrachtet.

– Ein Navigationssystem mit einer digitalen Straßenkarte. Dieses dient im Gegen-satz zur Positionsbestimmung der Routenbestimmung. Das Display des Naviga-tionssystems soll ggf. auch zur Visualisierung der VANET-Nachrichten genutzt


Rechnereinheit

ggf. TRHVerbindung zu den Fahrzeugsensoren

Navigationssystem mit Display

Smartcard-Leser(optional)

Zeitgeber

Transmitter Positionsbestimmungssystem

Digitaler Fahrtenschreiber

Abbildung 4.9: Im Fahrzeug vorausgesetzte Komponenten

werden. Es sind allerdings (je nach Anwendung) auch alternative Methoden zurAusgabe der Nachrichten an den Fahrer möglich, wie beispielsweise Head-up Dis-plays, Sprachausgabe, Lenkeingriffe etc.

– Eine Komponente, die Zugriff auf die Sensordaten des Fahrzeugs, wie sie z.B.von ABS, ESP, Motormanagement, Front- und Heckradar etc. geliefert werden,erlaubt.

– Ein digitaler Fahrtenschreiber, der verkehrskritische Meldungen und zugehörigeSensordaten ähnlich einer Blackbox in Flugzeugen speichert. Er ist für mancheAnwendungen (z.B. zur Rekonstruktion von Unfällen, Feststellung der Fahrzeu-ge in der Umgebung eines Unfalls etc.) hilfreich und dient dazu, die Umstände,die zum Senden einer Warnung geführt haben, beweisen zu können (siehe auchAbschnitt 4.3).

Abbildung 4.9 zeigt die in dieser Arbeit im Fahrzeug vorausgesetzten Komponenten inAnlehnung an die Darstellung in [HCL04].

• Jeder Teilnehmer in einem VANET nutzt und erbringt Dienste, solange er sich nichtegoistisch oder böswillig verhält. Egoistisch wird in einem VANET vor allem passivesVerhalten bezeichnet, wenn ein Knoten nur Dienste nutzt aber keine erbringt, z.B. keinePakete weiterleitet, um Ressourcen zu sparen (vgl. [Kar03]).

• Zugriff auf stationäre Netze wird bei einigen Lösungsvorschlägen vorausgesetzt bzw.ist Voraussetzung für bestimmte Anwendungen. Ein solcher Zugriff (vermittelt durchstationäre Transmitter) ist durchaus realistisch, da die Teilnehmer an Straßen gebundensind (siehe Abschnitt 2.1.2). Gerade in der Einführungsphase des VANETs, wenn noch

4.9 Annahmen 93

nicht viele stationäre Transmitter verfügbar sind, kann aber auch andere bereits existie-rende Infrastruktur wie beispielsweise UMTS einen solchen Zugriff ermöglichen. SollteKontakt mit anderen Netzen nötig sein, wird gesondert darauf hingewiesen.

• Probleme, die durch die Funkschnittstelle entstehen, werden nicht betrachtet. Dazu ge-hören beispielsweise Interferenzen (absichtlich oder versehentlich verursachte Störun-gen) zwischen Signalen oder die Ortung eines Senders durch Richtungsinformationeninnerhalb der elektromagnetischen Wellen, die er ausstrahlt. Es handelt sich hierbei umtechnische bzw. physikalische Probleme, die zwar durch verschiedene Technologien wieDSSS14 oder FH15 gemildert, aber nicht ausgeschlossen werden können (vgl. [Fed99]).Es wird die Annahme getroffen, dass Angriffe dieser Art durch organisatorische Maß-nahmen (wie z.B. Gesetzgebung) verhindert werden.

• Sensordaten, die innerhalb eines Fahrzeugs erhoben werden (z.B. durch ABS, ESP etc.),gelten als verlässlich und unverfälscht vorliegend. D.h. es wird nur die Kommunika-tion der Fahrzeuge untereinander und nicht die Kommunikation der einzelnen Kom-ponenten im Fahrzeug betrachtet. Um die Kommunikation der Komponenten inner-halb des Fahrzeugs abzusichern, könnten Methoden der Controller Authentikation undVerschlüsselung (siehe [WWP05]), der Komponentenidentifikation (z.B. in [WPW04]oder [HPWW05]) oder weitere Verfahren, wie sie beispielsweise in [And98] für digitaleTachometer aufgeführt werden, genutzt werden.

14DSSS (Direct Sequence Spread Spectrum): Spektrale Spreizung eines Nutzsignals mittels Modulation mit einerbreitbandigen Spreizsequenz, so dass das Nutzsignal nicht mehr vom Rauschen zu unterscheiden, aber vomEmpfänger durch die entsprechende Demodulation wiederherstellbar ist [Fed99].

15FH (Frequency Hopping): Wechseln der Trägerfrequenz einer Kommunikation nach einer zwischen Sender undEmpfänger vereinbarten Abfolge [Tan03].

Date post:	21-Dec-2016
Category:	Documents
Upload:	klaus
View:	219 times
Download:	4 times

Mehrseitig sichere Ad-hoc-Vernetzung von Fahrzeugen || Vorüberlegungen und Annahmen

Documents