Aspects of Privacy-Preserving Toll Pricing

Transkript

1 I n f o r m a t i k p r o j e k t T A. P A W I. F S Aspects of Privacy-Preserving Toll Pricing Eine Projektarbeit von Christoph Moser und Thomas Galliker Horw, 8. Februar 2012

2 Projekt Dokument Schule Modul Projektteam Dozent Experte Letzte Änderung Aspects of Privacy-Preserving Toll Pricing Report, TA.PAWI.FS2012 Galliker Thomas Studiengang Informatik (BB) Panorama 6123 Geiss Tel Dr. Marc Pouly Dr. Josef F. Bürgler 11. Februar 2012, 12:00:00 Uhr Moser Christoph Studiengang Informatik (VZ) Zugerbergstrasse Unterägeri Tel Selbständigkeitserklärung Hiermit erklären wir, dass die vorliegende Arbeit selbstständig angefertigt und keine anderen als die angegebenen Hilfsmittel verwendet wurden. Sämtliche verwendeten Textausschnitte, Zitate oder Inhalte anderer Verfasser wurden ausdrücklich als solche gekennzeichnet. Horw, 8. Februar 2012 Christoph Moser Thomas Galliker Änderungsprotokoll Version Datum Autor Beschreibung moc Initialversion von Vorlage erstellt moc Einleitung erstellt moc Kryptographische Grundlagen beschrieben gat Dokumentation Design-Entscheide GPS Heuristik gat/moc Bereinigung des Outlines, Kundenanforderungen ergänzt moc Kundenanforderungen überarbeitet gat Design-Entscheide dokumentiert moc Kryptographische Grundlagen überarbeitet moc Prozesse und Abläufe überarbeitet moc Vorteile und Schwachstellen dokumentiert gat Gefahren Privatsphäre, Kommunikation, Serialisierung gat/moc Korrekturen und Ergänzungen gat/moc Bereit für Abgabe

3 Abstract Auf den europäischen Strassen gibt es heute beinahe so viele verschiedene Ansätze zur Strassenfinanzierung, wie es in Europa souveräne Staaten gibt. Europa hat ein grosses Interesse, dieses sogenannte Road Pricing flächendeckend einzuführen und zwischen allen Staaten zu harmonisieren. Die EU möchte mit neuen Systemen das Verkehrs- und Staumanagement optimieren, die bestehende Infrastruktur effizienter nutzen und damit indirekt den CO2 Ausstoss reduzieren. Auch in der Schweiz gibt es Bestrebungen, ein elektronisches Road Pricing System einzuführen. Ein dynamisches Road Pricing Modell für alle Strassenbenutzer könnte dafür sorgen, dass die Infrastrukturkosten verhältnismässig auf die Verbraucher umgelegt werden. Technisch realisierbare Lösungen für ein elektronisches Road Pricing System gibt es offensichtlich viele. Leider stehen diese Lösungen oft im Konflikt mit dem Schutz der Privatsphäre des Benutzers, da diese oft vorsehen, Wegpfade oder andere sensible Informationen an eine Strassenverwaltung zu senden, um die Benutzungskosten abzurechnen. Das vorliegende Projekt befasst sich mit der Umsetzung eines Prototyps für ein Road Pricing System, welches die Privatsphäre des Benutzers kompromisslos schützt. Im Mittelpunkt der Analysen steht die Implementierung kryptographischer Methoden zur Verhinderung von Missbrauch ohne dabei auf aufgezeichnete Wegpfade zurückgreifen zu müssen. Ein spezielles Signaturverfahren stellt sicher, dass die für die Abrechnung von Strassenkilometern verwendeten Preise korrekt sind, während ein Challenge- Response Verfahren mit statistischen Mitteln sicherstellt, dass allfällige Manipulationen von aufgezeichneten Informationen aufgedeckt werden kann. Zum Einsatz kommen hierbei kryptographische Commitments zur Sicherung der Unveränderbarkeit von bestätigten Informationen sowie ein Zero-Knowledge Proof Schema zur Verifikation des Besitzes von Informationen, ohne dabei die Information an sich offenzulegen. Resultierend kann gesagt werden, dass solche Privacy-Preserving Electronic Toll Pricing (PrETP) Systeme eine reelle Chance haben, umgesetzt zu werden. Das vorliegende Projektsystem demonstriert, dass die vorgeschlagenen kryptographischen Algorithmen auf kostengünstigen Geräten effizient und sicher implementiert werden können.

4 Inhalt 1 Einleitung Road Pricing Aktuelle Situation Vor- und Nachteile des aktuellen Strassenbenutzungsgebühr Road Pricing in der EU Bestrebungen neues Road Pricing in der Schweiz Gefahren von neuen Road Pricing Technologien Kundenanforderungen Anforderungslisten Anwendungsfälle (Use Cases) Theoretische Grundlagen der Kryptographie Asymmetrische Kryptographie Message Digest Verfahren Commitment Schemas Zero-Knowledge Proof of Knowledge Softwarearchitektur Systemübersicht Komponentenübersicht Klassenübersicht Prozesse und Abläufe Datenstrukturen Spezifikation der Schnittstellen Design-Entscheide GPS Lokalisierung Preisberechnungsfunktion Updates von Karten- und Preisinformationen Persistenz Kommunikationsschicht Environment-Anforderungen Diskussion Praktische Umsetzung von PrETP Vorteile Schwierigkeiten einer praktischen Umsetzungen Mögliche Weiterentwicklungen Quellen APPENDIX Hinweise zu SQLite3 für Android GPS Lokationen simulieren... 62

5 Report Einleitung Road Pricing Abbildungsverzeichnis Abbildung 1: Mautstelle St.Michael in Österreich [30]... 8 Abbildung 2: Use Case Diagramm Abbildung 3: Schematische Darstellung der asymmetrischen Verschlüsslung mit RSA [7] Abbildung 4: Schematische Darstellung zum digitalen Signieren. Quelle: [35] Abbildung 5: Beispiele eines Münzwurfes per Telefon Abbildung 6: Elektronische Wahlen Abbildung 7: Höhle von Ali Baba [26] Abbildung 8: Systemübersicht Abbildung 9: Komponentendiagramm Abbildung 10: Klassen der Komponente tspservice Abbildung 11: Klassen der Komponente obuclient Abbildung 12: Zustandsdiagramm der Prozesse seitens OBU Abbildung 13: Zustandsdiagramm der Prozesse seitens OBU Abbildung 14: Ablauf Proof Challenge um Datenmanipulationen aufzudecken Abbildung 15: Physisches Entity-Relationship-Modell der TSP Datenbank Abbildung 16: Physisches Entity-Relationship-Modell, welches von TSP und OBU genutzt wird Abbildung 17: Physisches Entity-Relationship-Modell der OBU Datenbank Abbildung 18: Funktionsgraph zur Berechnung des mintime Parameters Abbildung 19: Funktionsgraph zur Berechnung des mindistance Parameters Abbildung 20: Kartenausschnitt von Horw (LU) mit vier Tarifzonen Abbildung 21: Eingrenzung des Suchraums Abbildung 22: Physische Konstellation des Kommunikationssystems Abbildung 23: Das Positionieren von Toll Charger bedingt das Einhalten bestimmter Regeln Abbildung 24: Zeitzonen in Europa [45] Abbildung 25: Abstecken der Zonen entlang der Strasse Tabellenverzeichnis Tabelle 1: Begriffe & Abkürzungen... 6 Tabelle 2: Funktionale Anforderungen an die Software Tabelle 3: Nicht-funktionale Anforderungen an die Software Tabelle 4: Use Case UC-01 - Wegpunkte aufzeichnen Tabelle 5: Use Case UC-02 Abrechnungsperiode verarbeiten Tabelle 6: Use Case UC-03-Beweis erfassen Tabelle 7: Use Case UC-04 - Beweis prüfen Tabelle 8: Vergleich der Varianten zur Berechnung des Kilometertarifs Tabelle 9: Anforderungen an die eingesetzte Systemumgebung Begriffe & Abkürzungen Abkürzung ASTRA CL-RSA CRUD DST DTO EETS gat GMT GPS Erklärung Bundesamt für Strassen Signaturalgorithmus von Camenisch und Lysyanskaya basierend auf RSA Create, Update, Delete Operationen einer Datenbank Daylight Saving Time; ein Zeit-Offset für die Umstellung zwischen Winter- und Sommerzeit Data Transfer Object; wird oft als Datentyp zum Austausch zwischen kommunizierenden Peers eingesetzt European electronic toll service Namenskürzel für Autor Thomas Galliker Greenwich Mean Time; ehem. als Weltzeit bekannt. Wird oft als Koordinationszeit herbeigezogen. Global Positioning System TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 5 / 62

6 Report Einleitung Road Pricing GSM HSLU IM IP JPA LSVA MD5 moc NSA OBU (Client) OBUDB Openfire ORM PrETP RPC RSA SHA1 SQLite TC TSP TSP Client TSP Service TSPDB UTC UVEK VPN XMPP Global System for Mobile Communication; Standard für digitale Mobilfunknetze Instant Messaging; bezeichnet das Übermitteln von Textnachrichten in Echtzeit Internet Protocol; weit verbreitetes Netzwerkprotokoll Java Persistance API; Java Schnittstelle für Datenbankverbindungen Leistungsabhängige Schwerverkehrsabgabe ist eine Steuer welche für Schwertransporte erhoben wird, abhängig von Gewicht und zurückgelegten Kilometern Message Digest 5; ein bis dato sicherer Hash-Algorithmus Namenskürzel für Autor Christoph Moser National Security Agency; US-amerikanische Sicherheitsbehörde On-board Unit; mobiles Computersystem zur Verrechnung der Fahrleistung und Abrechnung mit dem Toll Service Provider Datenbank von OBU Client XMPP Kommunikationsserver, Vermittlungspunkt für XMPP Clients Object-relational Mapping; eine Datenabstraktionsschicht zwischen Datenbank und Datenlogik, implementiert CRUD Operation sodass die Kopplung zwischen Logik und Daten gering gehalten kann Privacy-Preserving Electronic Toll Pricing; ein Strassenabrechnungssystem, welches die Privatsphäre des Anwenders schützt Remote Procedure Call; Aufruf von Prozeduren auf entfernten Systemen Rivest, Shamir, Adelson Algorithmus; asymmetrische Verschlüsselung/Signatur Secure Hash Algorithm 1; ein bis dato sicherer Hash-Algorithmus Dateibasiertes, leichtgewichtiges Datenbanksystem Toll Charger; Nummerschildscanner für die Beweiserfassung Toll Service Provider; staatlicher Strassenverwalter, erhebt und verrechnet Gebühren für die Benutzung von Strassen Client Applikation zur Verwaltung von TSP Service Service Applikation als zentrale Verwaltungsstelle des PrETP Systems Datenbank von TSP Service Tabelle 1: Begriffe & Abkürzungen Universal Coordinated Time; wird als Koordinationszeit verwendet, wenn verteilte Systeme miteinander kooperieren müssen. Das Eidgenössische Departement für Umwelt, Verkehr, Energie und Kommunikation Virtual Private Network; ein privates, sicheres Netzwerk, welches über ein öffentliches, unsicheres Netzwerk führt Extensible Messaging and Presence Protocol, ehem. Jabber, Kommunikationsprotokoll für Instant Messanging (Facebook Chat, Google Talk) TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 6 / 62

7 Report Einleitung Road Pricing 1 Einleitung Road Pricing Die Anzahl der registrierten Fahrzeuge ist in der Schweiz innerhalb von 10 Jahren von 4.0 Millionen auf 5.7 Millionen angestiegen [1]. Dies ist ein Anstieg von mehr als 30%. Um der Zunahme des Verkehrsaufkommens gerecht zu werden, muss die Verkehrsinfrastruktur laufend erweitert und gewartet werden. Die Schweizer Regierung ist verantwortlich für die Instandhaltung von ungefähr Kilometer öffentlicher Strassen [2]. Die Unterhaltsarbeiten und der Ausbau der Verkehrsinfrastruktur ist eine kostspielige Angelegenheit. Die entscheidende Frage ist, wie die anfallenden Kosten fair auf den jeweiligen Nutzer übertragen werden können. 1.1 Aktuelle Situation In der Schweiz werden die öffentlichen Strassen hauptsächlich über das Verbraucher-Prinzip finanziert. Die Haupteinnahmequelle ist dabei die Mineralölsteuer, welche beim Import von Benzin erhoben wird. Hinzu kommt eine jährliche Motorfahrzeugsteuer, welche von der Energieeffizienz des Fahrzeuges abhängig ist. Für die Benutzung von Autobahnen und Schnellstrassen wird zudem eine Vignette (40 CHF pro Jahr) benötigt. Für den Schwerverkehr wird eine zusätzliche Steuer, die sogenannte LSVA, erhoben, welche abhängig vom Gewicht des Fahrzeugs und den zurückgelegten Kilometer ist. Insgesamt generiert der Staat dadurch jährlich 8.8 Milliarden CHF für den Unterhalt der öffentlichen Strassen [3]. Wenn man die Erträge mit den Ausgaben für den Unterhalt vergleicht, erreicht man einen Gesamtkostendeckungsgrad von 92% [4]. 1.2 Vor- und Nachteile des aktuellen Strassenbenutzungsgebühr Der grosse Vorteil der aktuellen Strassenbenutzungsgebühr ist die Einfachheit der Verrechnung. Die Mineralölsteuern werden bereits von den Importeuren bezahlt und somit ohne grossen administrativen Aufwand auf den Verbraucher übertragen. Wenn mehr Mittel für den Unterhalt der Strassen benötigt werden, kann dies durch eine Erhöhung der Mineralölsteuer relativ einfach erzielt werden. Das aktuelle System birgt allerdings auch einige Nachteile. Beispielsweise ist die Verteilung der Kosten für den Transit-Verkehr nicht optimal gelöst. Autolenker welche die Schweiz an einem Tag durchqueren, müssen eine Vignette für 40 CHF erwerben, welche für ein ganzes Jahr gültig wäre. Anderseits hat die Regierung keine Möglichkeit sicherzustellen, dass der Transit-Verkehr die Benutzung der Strasseninfrastruktur über die Mineralölsteuer bezahlt. Denn Personen auf der Durchfahrt können nicht zu einem Tankstopp gezwungen werden. Mit dem aktuellen System kostet jeder Kilometer gleich viel, unabhängig von der Zeit und dem Strassentyp (Autobahn, Landstrasse) welcher befahren wurde. Dieses System lässt somit keine Verkehrsregulierung zu, wodurch stark befahren Strassen während den Stosszeiten stärker besteuert werden könnten um Staus zu verhindern. TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 7 / 62

8 Report Einleitung Road Pricing 1.3 Road Pricing in der EU Jedes europäische Land verwendet ihre eigenen Standards und Systeme um Strassenbenutzungsgebühren zu verrechnen. In vielen Ländern müssen die Fahrzeuglenker an sogenannten Mautstationen anhalten um den Betrag für das Benutzen der Strasseninfrastruktur zu entrichten. Der Bezahlungsvorgang dauert ungefähr 30 Sekunden, deshalb sind die Mautstationen häufig ein Auslöser für Verkehrstaus. Abbildung 1: Mautstelle St.Michael in Österreich [30] Durch den Einsatz von unterschiedlichen Mautsystemen, benötigt ein LKW beim Durchqueren von mehreren europäischen Ländern verschiedene Bordgeräte und die zugehörigen Verträge. Deshalb hat die EU im Oktober 2009 entschieden, dass künftig ein einheitliches Mautsystem eingesetzt werden soll. Dadurch erhofft man sich, dass die Wartezeiten an den Mautstationen verkürzt werden können. [29] Die Anforderungen an den Europäischen Elektronischen Mautdienst (EETS) sehen vor, dass dynamische Preismodelle verwendet werden können, ohne dadurch die Privatsphäre des Fahrzeughalters zu verletzen. Ein dynamisches Preismodell erlaubt es, das Verkehrsaufkommen abhängig von Strassentyp und Zeitfenster zu regulieren. Das Europäische Mautsystem ermöglicht es einem Fahrzeughalter den Dienstleister frei zu wählen und sich bei diesem zu registrieren. Die Dienstleister erhalten dann von der Maut erhebenden Stelle die Mautgebühr, welche für eine bestimmte Periode verrechnet wurde. Der Dienstleister fordert die Mautgebühren direkt beim Fahrzeuglenker ein. [29] Gemäss der Planung, welche im Jahr 2009 für die Einführung eines einheitlichen Europäischen Mautsystems gemacht wurde, sollte Ende 2012 der EETS-Dienst für alle Strassenfahrzeuge über 3.5 Tonnen zur Verfügung stehen. Für die restlichen Fahrzeuge ist die Einführung des EETS-Dienstes im Jahre 2015 geplant. [29] 1.4 Bestrebungen neues Road Pricing in der Schweiz Im Jahr 2010 hat das Bundesamt für Strassen ASTRA Staustunden erfasst [5]. Durch das zunehmende Verkehrsaufkommen in den Agglomerationen und die positiven Erfahrungen mit neuen Road Pricing Technologien im In- und Ausland (LSVA, Stauabgaben in Stockholm) hat die Ausarbeitung eines neuen Systems in der Schweiz an Bedeutung gewonnen. Vor der Einführung der LSVA im Jahre 2000 hat die Anzahl der gefahrenen Kilometer von schweren Motorfahrzeugen laufend zugenommen. Durch die Einführung der LSVA konnte dieser Trend gestoppt werden und dadurch wurde der Schwerverkehr in den ersten vier Jahren um 7% reduziert. Es gibt auch positive Beispiele im Ausland. In Stockholm beispielsweise wurde ein System eingeführt, bei welchem beim Befahren des Stadtzentrums nach Tageszeit abgestufte Tarife verrechnet werden. Während einer Versuchsdauer von 6 Monaten wurde festgestellt, dass die Staus um 30-50% zurückgingen. [6] TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 8 / 62

9 Report Einleitung Road Pricing Gemäss dem UVEK ist das primäre Ziel von einem Road Pricing System in der Schweiz, das Verkehrsproblem in den Städten und Agglomerationen zu entschärfen. Die Finanzierung der Strasseninfrastruktur steht nicht im Vordergrund, weil die Finanzierung mit dem heutigen Abgabesystem gut gedeckt ist. Mittel- bis langfristig wird allerdings der Treibstoffverbrauch zurückgehen, da vermehrt auf effizientere Fahrzeuge oder Fahrzeuge mit alternativen Antrieben gesetzt wird. Langfristig gesehen werden somit die Einnahmen durch die Mineralölsteuern zurückgehen. Dadurch muss auch das Finanzierungskonzept für die Strasseninfrastruktur überarbeitet werden [6]. 1.5 Gefahren von neuen Road Pricing Technologien Wenn bewährte Systeme durch neue, elektronische Systeme ersetzt werden, bestehen selbstverständlich immer gewisse Bedenken bezüglich dem Schutz der Privatsphäre der Anwender. Das Geschäft mit Anwenderdaten durchlebt zurzeit einen riesen Boom. Selbst wenn man davon ausgeht, dass ein Staat grundsätzlich kein kommerzielles Interesse an gesammelten Informationen hat, besteht immer das Risiko, dass diese Daten in falsche Hände gelangen. GPS Wegpunkte erlauben viel mehr als nur die Bestimmung der gefahrenen Distanz. Die Abschnittszeiten würden nachträgliche Geschwindigkeitsberechnungen zulassen. Zusammen mit dem Strassentyp könnte die Polizei beispielsweise im Nachhinein Bussen ausstellen. Im Falle eines Unfalls könnte erwiesen werden, dass eines der involvierten Fahrzeuge mit übertretener Geschwindigkeit unterwegs war. Die Analysen könnten so weit gehen, dass man sogar das Fahrverhalten eines Fahrers bestimmen könnte. Willkommen im Überwachungsstaat! Versicherungen und andere profitorientierte Unternehmen haben ein reges Interesse an solchen Informationen [36]. Das Beispiel des britischen Fahrzeugversicherers Norwich Union zeigt, dass der Schutz der Privatsphäre mit viel Marketing übermalt werden kann [37]. Selbst wenn die Daten verschlossen beim Strassenverkehrsamt gelagert werden und alles unternommen wird, dass diese nur zweckgemäss genutzt werden: Das Risiko besteht immer, dass Informationen entwendet und missbraucht werden. Finanzielle Anreize machen die besten Sicherheitsmechanismen nutzlos. Wie einfach wäre es den, einen Präsidentschaftskandidaten auszuschalten, wenn man seine exakte Spur - wenn möglich sogar in Echtzeit - kennt? Wie schnell könnte man einen Skandal aufziehen, wenn man feststellen würde, dass die GPS Spuren eines ranghohen Politikers regelmässig ins Rotlichtmillieu zeigen? TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 9 / 62

10 Report Kundenanforderungen 2 Kundenanforderungen Dieses Kapitel enthält zwei wichtige Unterkapitel: Die Anforderungsliste mit den funktionalen und nichtfunktionalen Anforderungen sowie die Anwendungsfälle (Geschäftsprozesse), welche dieses System bereitstellen muss. 2.1 Anforderungslisten Die Anforderungen in den nachfolgenden Tabellen sind möglichst lösungsneutral abgefasst. Konkrete Beispiele dienen nur zum Illustrationszweck. Die Anforderungserhebung wurde in folgende zwei Kategorien aufgeteilt: Funktionale und nichtfunktionale Anforderungen. Als funktionale Anforderung gelten Leistungen, welche das Softwareprodukt erbringen soll (z.b. Funktion X, Funktion Y). Nichtfunktionale Anforderungen sind Eigenschaften und Zusatzleistungen, welche nicht direkt als programmierte Funktionen umgesetzt werden können (z.b. Wartbarkeit, Benutzerfreundlichkeit, Look and Feel) Liste der funktionalen Anforderungen Nr. F M W Bezeichnung 1 GPS Lokalisierung Werte Daten Erläuterungen Änderungen 1.1 M Erfassen der Position Die OBU muss in der Lage sein, GPS Positionen mit einer konfigurierbaren Genauigkeit und in einem idealen Intervall zu erfassen. 1.2 M Zuordnung der Preiszone Um den Kilometertarif berechnen zu können, muss die OBU anhand von GPS Positionsinformationen feststellen können, in welcher Preiszone sie sich befindet. 2 OBU 2.1 M Aktuelle Preispläne abfragen Die OBU kann beim TSP aktuelle Preispläne anfordern. Die Preispläne werden benötigt, um für eine befahrene Strecke den korrekten Preis zu verrechnen. 2.2 W Streckenpreis anzeigen Auf dem GUI der OBU soll der Preis der gegenwärtig befahrenen Strasse angezeigt werden. Damit der Benutzer weiss, welcher Tarif für die befahrene Strecke verrechnet wird und so allenfalls eine alternative Route wählen kann. 2.3 W Zwischensumme anzeigen Es soll die Zwischensumme der aktuellen Abrechnungsperiode auf dem GUI des OBU Clients angezeigt werden. 3 TSP 3.1 M Beweise erfassen Über ein User-Interface können Beweise erfasst werden. Ein Beweis sagt aus, dass sich ein bestimmtes Fahrzeug zu einem bestimmten Zeitpunkt an einem bestimmten Ort aufgehalten hat. TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 10 / 62

11 Report Kundenanforderungen 3.2 M Beweise anzeigen Die erfassten Beweise inklusive Status (offen, korrekt, inkorrekt) können angezeigt werden. 3.3 M Abrechnung ausführen Es kann eine Abrechnung für ein bestimmtes Fahrzeug gestartet werden. Während der Abrechnungsphase werden die übertragenen Daten auf Manipulationen geprüft. 3.4 M Beweise prüfen Der TSP prüft, ob für den Zeitpunkt an welchem der Beweis erfasst wurde, die korrekten Lokationsdaten eingegangen sind. Zudem wird geprüft, ob die OBU für die Strecke den korrekten Preis rapportiert hat. 3.5 M Abrechnung anzeigen Die ausgeführten Abrechnungen können im TSP angezeigt werden, dabei ist ersichtlich, welche Beweise während der Abrechnung geprüft wurden. Tabelle 2: Funktionale Anforderungen an die Software Liste der nicht-funktionalen Anforderungen Nr. F M W Bezeichnung 1 Leistung Werte Daten Erläuterungen Änderungen 1.1 W Effizienz Insbesondere auf den eingesetzten Geräten (OBU) in Fahrzeugen soll darauf geachtet werden, dass die vorhandenen Ressourcen effizient genutzt werden können. Es sollen nur jene Informationen gesammelt werden, die zur Weiterverarbeitung notwendig sind. Bei Nichtgebrauch müssen diese umgehend gelöscht werden. Ein weiteres Augenmerk gilt es der Datenübertragung von OBU zu TSP (und umgekehrt) zu schenken. Dort können variable Kosten anfallen. 1.2 M Effektivität Um die Ressourcen der OBU zu schonen, soll auch auf die Effektivität der ausgeführten Operationen geachtet werden. 1.3 W Antwortzeit Die Antwortzeit von Anfragen sollen unter zwei Sekunden gehalten werden. Andernfalls muss der Prozess asynchron implementiert werden. 2 Benutzbarkeit 2.1 M Einfache Erlernbarkeit Der Benutzer kann die gewünschten Funktionen mit geringem Vorwissen erfolgreich benutzen. 2.2 AM Logischer Aufbau Abläufe der Funktionen in der Software sind gut strukturiert und selbsterklärend. 2.3 M Dialogschritte Dialoge sind verständlich und geben bei Bedarf Rückmeldungen an den Benutzer. TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 11 / 62

12 Report Kundenanforderungen 2.4 W Look & Feel Das GUI soll ansprechend gestaltet sein. Selbsterklärende Icons und Grafiken sollen für einfache Benutzung wichtiger Funktionen eingesetzt werden. 2.5 W Erwartungskonformität Dialoge sind konsistent mit den Erwartungen des Benutzers. 2.6 W Cursor Bewegung des Cursors auf ein Minimum reduzieren. - Cursor bereits in erstes Feld setzen - Navigation mit sinnvoller Tabulator-Reihenfolge ermöglichen 3 Sicherheit 3.1 M Schutz der Privatsphäre Das oberste Prinzip des Gesamtsystems ist es, die Privatsphäre bei jeder Aktion und zu jedem Zeitpunkt kompromisslos zu schützen. Die übertragenen Daten müssen kryptographisch signiert und verschlüsselt werden. 3.2 M Manipulationsschutz Mittels kryptographischer Methoden soll sichergestellt werden, dass die OBU keine zur Berechnung der Strassennutzungsgebühr verwendeten Attribute manipulieren kann. Dies gilt insbesondere für die aufgezeichnete Strecke sowie für die verrechneten Kilometertarife. 3.3 M Positionsnachweis Mit Hilfe von Spot Checks soll geprüft werden können, ob die aufgezeichneten Lokationsdaten und Preise, welche die OBU gemeldet hat, korrekt sind. 4 Verschiedenes 4.1 W Wartbarkeit Der Code soll so konstruiert werden, dass Änderungen im Nachhinein möglich sind und einen möglichst kleinen Einfluss auf bestehenden Code haben. Tabelle 3: Nicht-funktionale Anforderungen an die Software F = Festanforderung M = Mindestanforderung W = Wunschanforderung TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 12 / 62

13 Report Kundenanforderungen 2.2 Anwendungsfälle (Use Cases) Ein Anwendungsfall (engl. Use Case) stellt ein konkretes Szenario dar, welches eintreten kann, wenn ein Akteur mit Hilfe einer Software-Funktion ein bestimmtes Ziel erreichen will. Im nachfolgenden Abschnitt werden die vorgesehenen Anwendungsfälle nach einer einheitlichen Schablone (Alistair Cockburn, 2001) dargestellt und beschrieben. Abbildung 2: Use Case Diagramm UC-01: Wegpunkt aufzeichnen Identifikation Name Beschreibung Akteure Vorbedingungen Standardablauf Alternativer Ablauf - Nachbedingungen - Bemerkung UC-01 Wegpunkt aufzeichnen Ein Fahrzeug legt eine beliebige Strecke zurück. Während der Fahrt werden Wegpunkte aufgezeichnet, welche vom Fahrzeug passiert wurden 1. GPS Sensor (erkennt das sich die Koordination geändert haben) OBU initialisiert GPS Empfang 1. GPS-Daten werden abgefragt. 2. Die erhaltenen Koordinaten werden zusammen mit dem Zeitstempel auf der On-board Unit gespeichert. Der Intervall welcher festlegt, wie häufig Daten aufgezeichnet werden, soll die Fahrgeschwindigkeit mitberücksichtigen. Status Entwurf In Überarbeitung Abgeschlossen TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 13 / 62

14 Report Kundenanforderungen Änderungen Datum Use Case owner Kommentar Tabelle 4: Use Case UC-01 - Wegpunkte aufzeichnen Christoph Moser Erste Version UC-02: Abrechnungsperiode verarbeiten Identifikation Name Beschreibung Akteure Vorbedingungen Standardablauf Alternativer Ablauf Nachbedingungen - Bemerkung Christoph Moser UseCase überarbeitet UC-02 Abrechnungsperiode verarbeiten Ein Mitarbeiter vom Strassenverkehrsamt startet die Abrechnung eines Fahrzeuges respektive derer On-board Unit. Während der Abrechnungsphase werden die übertragenen Daten auf Manipulationen geprüft. 1. Ein Mitarbeiter vom Strassenverkehrsamt Der Toll Service Provider verfügt über die aktuellen Preisinformationen, sowie einer Historie der älteren Preise 1. Der Mitarbeiter wählt im TSP Client das Fahrzeug für welches die Abrechnung gestartet werden soll. 2. Die von der OBU aufgezeichneten Wegpunkte werden mit Hilfe von kryptographischen Primitiven an den TSP übermittelt, sodass der TSP aus den erhaltenen Daten die aufgezeichneten Wegpunkte nicht herleiten kann. 3. Der TSP prüft anhand kryptographische Protokolle, ob die erhaltenen Daten korrekt sind. 4. Der TSP ermittelt den Totalpreis für die Abrechnungsperiode. 5. Der Totalpreis wird an die Verrechnungsstelle weitergeleitet. Der Mitarbeiter wird informiert falls Fehlerhafte/Manipulierte Daten übertragen wurden. Keine Status Entwurf In Überarbeitung Abgeschlossen Änderungen Datum Use Case owner Kommentar Christoph Moser Erste Version Christoph Moser UseCase überarbeitet Tabelle 5: Use Case UC-02 Abrechnungsperiode verarbeiten UC-03: Beweis erfassen Identifikation Name Beschreibung Akteure Vorbedingungen Standardablauf Alternativer Ablauf - Nachbedingungen - UC-03 Beweis erfassen Der Toll-Charger erfasst einen Beweis, dass sich ein Fahrzeug zu einem bestimmten Zeitpunkt an einem bestimmten Ort aufgehalten hat. 1. Toll-Charger Fahrzeug passiert Toll-Charger 1. Ein Beweis wird in einer Eingabemaske erfasst 2. Der Beweis wird gespeichert TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 14 / 62

15 Report Kundenanforderungen Bemerkung Keine Status Entwurf In Überarbeitung Abgeschlossen Änderungen Datum Use Case owner Kommentar Tabelle 6: Use Case UC-03-Beweis erfassen UC-04: Beweis prüfen Identifikation Name Beschreibung Akteure Vorbedingungen Standardablauf Alternativer Ablauf - Nachbedingungen - Bemerkung Christoph Moser Erste Version UC-04 Beweis prüfen Der TSP weiss anhand eines Beweises, dass sich ein Fahrzeug zum Zeitpunkt als der Beweis aufgezeichnet wurde, am Ort wo der Beweis festgehalten wurde, befunden haben muss. Dadurch kann der TSP prüfen, ob für diesen Zeitpunkt die korrekten Lokationsdaten gemeldet wurden. Zudem wird geprüft, ob die OBU für die Strecke den korrekten Preis rapportiert hatte. 1. Mitarbeiter vom Strassenverkehrsamt Die Payment Tuple wurde von der On-board Unit zum Toll Service Provider übertragen (UC 02) Die On-board Unit muss erreichbar sein, damit die Challenges geprüft werden können 1. Der Mitarbeiter gibt das Kennzeichen für das zu prüfende Fahrzeug ein. 2. Für jeden erfassten Beweis werden die folgenden Schritt ausgeführt: 2.1 Der TSP sendet den Beweis als Challenge an die OBU. 2.2 Die OBU prüft, ob der Beweis von einem gültigen Toll Charger stammt. 2.3 Die OBU sucht den passenden Payment Record zur empfangenen Challenge und sendet diesen als Antwort zurück an den TSP. 2.4 Der TSP prüft, ob die Challenge von der OBU korrekt beantwortet wurde. 2.5 Der TSP prüft, ob der übermittelte Preis in der Antwort zur Challenge bereits während der Abrechnung (UC-02) rapportiert wurde. 2.6 Der TSP prüft, ob er für den Zeitpunkt und Ort an welchem sich das Fahrzeug aufgehalten hat, denselben Preis verrechnet hätte. 2.7 Der Status der Challenge wird gespeichert. 3. Eine Auswertung der geprüften Challenges und der dazugehörigen Resultate, wird dem Mitarbeiter angezeigt. Keine Status Entwurf In Überarbeitung Abgeschlossen Änderungen Datum Use Case owner Kommentar Tabelle 7: Use Case UC-04 - Beweis prüfen Christoph Moser Erste Version Christoph Moser UseCase überarbeitet TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 15 / 62

16 Report Theoretische Grundlagen der Kryptographie 3 Theoretische Grundlagen der Kryptographie In diesem Kapitel werden jene kryptographischen Primitive dokumentiert, welche dieses Projekt in irgendeinem Zusammenhang tangieren. Neben der allgemeinen Funktionsweise, dem Einsatzzweck und generellen Beispielen wird auch versucht aufzuzeigen, wie die kryptographischen Protokolle im vorliegenden Projekt zum Einsatz kommen. 3.1 Asymmetrische Kryptographie Im Gegensatz zu symmetrischen Verschlüsselungsverfahren besitzen die beiden kommunizierenden Parteien beim asymmetrischen Verfahren keinen gemeinsamen Schlüssel, um Informationen zu verschlüsseln bzw. entschlüsseln. Jeder Teilnehmer besitzt ein Schlüsselpaar, welches aus einem öffentlichen (Public Key) und einem privaten Schlüssel (Private Key) besteht. Der öffentliche Schlüssel kann, wie es der Name bereits besagt, öffentlich bekannt gemacht werden. Beispielsweise durch das Publizieren auf einer Webseite. Der Public Key von Teilnehmer x wird dann von anderen Teilnehmern verwendet, um eine verschlüsselte Nachricht an Teilnehmer x zu senden. Der Private Key wird nicht weitergegeben. Dieser wird zur Entschlüsselung und zum Signieren von Nachrichten genutzt. Anforderungen an eine Asymmetrische Kryptographie: [7] Es wird ein öffentlicher Schlüssel K + und ein privater Schlüssel K - benötigt, sodass K - (K + (m)) = m Es ist nicht möglich anhand des privaten Schlüssels K - den öffentlichen Schlüssel K + zu berechnen Asymmetrische Kryptographie-Algorithmen Es gibt verschiedene asymmetrische Kryptographie-Algorithmen, welche auf unterschiedlichen mathematischen Problemen basieren. Die bekanntesten asymmetrischen Kryptographie-Algorithmen sind: RSA (Rivest, Shamir, Adelson Algorithmus) macht Gebrauch davon, dass es rechen- und dadurch zeitintensiv ist, aus einem grossen Produkt zweier Primzahlen, die beiden Primfaktoren zu ermitteln. Mit heute verfügbaren Mitteln ist es nicht möglich, innerhalb sinnvoller Zeit aus einem öffentlichen Schlüssel den privaten Schlüssel zu berechnen [8]. Im Zusammenhang mit RSA wird manchmal auch von einem symmetrischen Algorithmus gesprochen. Diese Bezeichnung meint aber lediglich, dass beim Ver- und Entschlüsseln jeweils derselbe mathematische Prozess genutzt wird jedoch einmal mit dem Public Key und einmal mit dem Private Key. DSA (Digital Signature Algorithm) ein von der NSA entwickeltes Signaturverfahren. Im Gegensatz zu RSA kann DSA nur zum Signieren von Informationen verwendet werden. Der Algorithmus basiert auf dem zahlentheoretischen Problem des diskreten Logarithmus. Er bedient sich also des mathematischen Vorteils, dass das Berechnen von Exponenten wesentlich einfacher ist, als das Zerlegen eines Expontentialprodukts in die gesuchte Basis und Exponent. Elgamal ist ein Verschlüsselungs- und Signaturalgorithmus, welcher ebenfalls auf dem Problem des diskreten Logarithmus aufbaut. Im Gegensatz zu RSA verwendet Elgamal zum Verschlüsseln und Signieren unterschiedliche mathematische Vorgänge. TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 16 / 62

17 Report Theoretische Grundlagen der Kryptographie RSA Verschlüsslung Durch das verschlüsselte Übertragen einer Nachricht wird verhindert, dass ein Angreifer eine abgehörte Nachricht lesen kann. In der Abbildung 3 ist ersichtlich, dass Alice eine Nachricht m mit dem öffentlichen Schlüssel von Bob K + verschlüsselt an Bob sendet. Bob kann nun die verschlüsselte Nachricht mit seinem privaten Schüssel K - entschlüsseln. Somit ist sichergestellt, dass nur Bob diese Nachricht öffnen kann. Abbildung 3: Schematische Darstellung der asymmetrischen Verschlüsslung mit RSA [7] Der RSA Algorithmus Der RSA Algorithmus arbeitet exakt nach dem oben beschriebenen Prinzip. Bevor es zum verschlüsselten Informationsaustausch kommt, müssen sich die Teilnehmer Schlüssel erstellen. Dafür generieren sie jeweils zuerst zwei distinkte Primzahlen, p und q. Das Produkt dieser beiden Zahlen sei n. Die Bitlänge von n wird typischerweise als Schlüssellänge bezeichnet. Nach Empfehlungen von RSA Laboratories [18] ist es aus sicherheitstechnischen Gründen empfehlenswert, Schlüssellängen zu verwenden, also 1024bit, 2048bit oder 4096bit. Eine längere Schlüssellänge verbessert grundsätzlich die Sicherheit von RSA Verschlüsselungen, kostet aber viel mehr Rechenleistung als kleinere Schlüssel. Es gilt sich also zu überlegen, wie lange eine bestimmte Information geheim gehalten werden möchte, bis ein potenzieller Abhörer eine Nachricht entschlüsselt hat. l n > Als nächstes wird eine Zahl e (=Encryption Key) gesucht, welche mit der Zahl phi=(p-1)(q-1) keinen gemeinsamen Teiler hat, also sog. co-prime ist. Passend zu e wird eine Zahl d (=Decryption Key) gesucht, welche die Gleichung e*d mod phi = 1 erfüllt. Für diese Berechnung einer multiplikativ-inversen Zahl von e wird der extended Euclid Algorithmus verwendet. Dieser ist im Gegensatz zum herkömmlichen Euclid Algorithmus effizienter. Der Private Key setzt sich nun aus dem Zahlenpaar {d,n} zusammen, während das Zahlenpaar {e,n} als Public Key veröffentlicht wird. Für den Besitzer des Public Keys ist es schwierig, mit Hilfe von e und n auf d zu schliessen. Fände der Besitzer eines fremden Public Keys eine einfache Möglichkeit, n in die Faktoren p und q zu zerlegen, so könnte er sich den Decryption Key d berechnen und Informationen entschlüsseln. Auf dieser Annahme, dass das Faktorisieren von grossen Primzahlen aufwändig ist, basiert die Sicherheit von RSA. TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 17 / 62

18 Report Theoretische Grundlagen der Kryptographie Die Verschlüsselungsfunktion in RSA ist definiert als y = E(x) = x e mod n, wobei x die zu verschlüsselnde Nachricht ist und y der gewünschte Ciphertext. Die Entschlüsselungsfunktion wird in RSA nicht nur zum Entschlüsseln von verschlüsselten Daten gebraucht, sondern auch zum Signieren von Klartext-Informationen. Die Funktion lautet x = D(y) = y d mod n, also dieselbe mathematische Operation, welche bereits beim Verschlüsslungsprozess eingesetzt wird, jedoch mit Hilfe der multiplikativ-inversen Zahl d Anwendungsbeispiel Ein einfaches Zahlenbeispiel soll die Funktionsweise von RSA illustrieren. Für Demonstrationszwecken wurden absichtlich sehr kleine Sicherheitsparameter gewählt. 1. Wähle zwei Primzahlen, p=3 und q= Berechne n=p*q=33. Berechne phi=(p-1)(q-1)= Wähle eine Zufallszahl e, welche keinen gemeinsamen Teiler mit phi hat: Beispielsweise e=3, da gcd(3,20)=1 4. Finde d sodass e*d mod phi = 1. Mit dem extendedeuclid(e, phi) findet man d=7. 5. Der Ciphertext für die Zahl x=9 wird wie folgt berechnet: y=e(x) = x e mod n = 9 3 mod 33 = 3 6. Die verschlüsselte Zahl y=3 kann danach wieder in Klartext umgewandelt werden: x=d(y) = y d mod n = 3 7 mod 33 = 9 Dass Verschlüsselung und Entschlüsselungen komplett symmetrische Operationen sind, zeigen die beiden Zahlenbeispiele: Entschlüsselung(Verschlüsselung(x)) = x Verschlüsselung (Entschlüsselung(y)) = y D(E(x)) = x (x e mod n) d mod n = x (9 3 mod 33) 7 mod 33 = 9 E(D(y)) = y (y d mod n) e mod n = y (3 7 mod 33) 3 mod 33 = Verschlüsseln grosser Datenmengen Das Verschlüsseln von grossen Informationsmengen mit asymmetrischen Kryptographie-Algorithmen kostet unter Berücksichtigung äquivalenter Sicherheit viel mehr Zeit als mit symmetrischen Algorithmen. In der Praxis werden daher diese beiden Verfahren oft hybrid genutzt: Ein (oft temporärer) symmetrischer Key wird genutzt, um die Nutzdaten zu verschlüsseln. Danach wird dieser symmetrische Key mit einem asymmetrischen Public Key verschlüsselt. Dieses Prinzip kommt bei GnuPG zum Einsatz [19]. TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 18 / 62

19 Report Theoretische Grundlagen der Kryptographie Digitale Signaturen Als digitales Signieren bezeichnet man den Vorgang des Verschlüsselns von Informationen unter Verwendung des Private Keys. Da grundsätzlich jeder im Besitz des dazugehörigen Public Keys sein kann, wird bei diesem Vorgang nicht die Vertraulichkeit, sondern die Authentizität der übertragenen Nachricht sichergestellt. Wenn eine Nachricht eine Signatur von Alice enthält, so kann Bob davon ausgehen, dass die Nachricht von Alice stammt, da nur sie im Besitz des Private Key s ist. Eine Analogie zur elektronischen Signatur ist die handschriftliche Signatur. Abbildung 4: Schematische Darstellung zum digitalen Signieren. Quelle: [35] Signieren von grossen Datenmengen Das Signieren von grossen Informationsmengen mit asymmetrischen Algorithmen kostet, speziell bei grossen Schlüssellängen, sehr viel Zeit. Deshalb wird von den Informationen vorgängig, unter Beizug eines Message Digest Algorithmus, ein Hash erstellt (Kapitel 3.2, Seite 20). Dieser Hash wird anschliessend signiert Das CL-RSA Signatur Schema Der von Camenisch und Lysyanskaya eingeführte CL-RSA Signaturalgorithmus basiert weitgehend auf demselben Prinzip wie RSA 1. Eingesetzt wurde dieser Algorithmus erstmals in einem Authentifizierungssystem, dem Identity Mixer Anonymous Credential System [31][32]. Mit CL-RSA kann eine Entität prüfen, ob eine andere Entität im Besitz einer Signatur ist, ohne dass eine der Parteien die Signatur oder die signierte Nachricht preisgeben muss. In diesem Projekt werden CL-RSA Signaturen im Zusammenhang mit den Zonentarifen verwendet. Jeder konfigurierte Preis eines Pricing Profiles wird zusätzlich mit einer CL-RSA Signatur versehen. Diese Signaturen werden durch den TSP mit dem Private Key des TSP s erstellt. Die OBU Clients laden die Signaturen zusammen mit den Pricing Profiles beim Systemstart und vor dem Abrechnungsvorgang. Beim Aufzeichnen von Payment Records speichert die OBU neben dem für den erstellten Payment Record verwendeten Preis auch einen Proof, in welchem die CL-RSA Signatur zum Einsatz kommt. Der TSP kann später anhand des Proof s verifizieren, ob in der Abrechnung die von ihm signierten Zonentarife verwendet wurden. 1 In CL-RSA werden lediglich die Werte für p und q anders bestimmt als in RSA. Siehe [34]. TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 19 / 62

20 Report Theoretische Grundlagen der Kryptographie 3.2 Message Digest Verfahren Ein Hash (auch bekannt als Message Digest) ist eine mathematische Einweg-Funktion. Mit Hashfunktionen können Eingabewerte in idealerweise eindeutige Fingerabdrücke gewandelt werden. Der Vorteil von Hashfunktionen liegt in der Unumkehrbarkeit der Berechnung: Ein Hash ist einfach berechenbar aber schwer umkehrbar. Als sichere Hashverfahren gelten heute Message Digest 5 (kurz MD5) und Secure Hash Algorithm 1 (SHA1). Allgemeine Eigenschaften von Hashfunktionen: Unumkehrbarkeit: Es ist nicht möglich aus dem Ausgabewert den Eingabewert zu ermitteln. Kollisionsresistent: Es ist schwierig zwei unterschiedlichen Eingabewerten zu finden welche den gleichen Ausgabewert erzielen. Message Digest wird beispielsweise eingesetzt, um die Integrität bei der Übermittlung einer Nachricht sicherzustellen. Dies wird bewerkstelligt, indem zusätzlich zur verschlüsselten Nachricht ein signierter Hash der Nachricht mitübertragen wird. Der Empfänger kann den Hash dieser Nachricht generieren und diesen mit dem Hash, welcher der Absenders mitgesendet hat, vergleichen. Sind die Hashes identisch dann ist sichergestellt, dass die Nachricht während der Übertragung nicht von einem Angreifer verändert wurde. [28] 3.3 Commitment Schemas Ein Commitment Schema ist eine Verfahren zwischen zwei Teilnehmern, welches erlaubt, dass sich ein Teilnehmer auf einen Wert festlegt und sich zu diesem Wert gegenüber dem anderen Teilnehmer verpflichtet, ohne den festgelegten Wert preiszugeben. Das heisst, der Teilnehmer, welcher den Wert festgelegt hat, kann den Wert nachträglich nicht mehr ändern, er hat sich dazu committed. Eine Analogie zum kryptographischen Commitment Schema ist das Hinterlegen einer Nachricht in einem versigelten Umschlag beim Kommunikationspartner. Ein Commitment Schema hat somit die folgenden Eigenschaften [24]: Eindeutigkeit (binding property): Der Sender kann den Wert nach der Festlegungsphase nicht mehr ändern. Geheimhaltung (hiding property): Für den Empfänger ist es nicht möglich ein Commitment des Werts 1 von einem Commitment des Werts 0 zu unterscheiden. In der Abbildung 5 wird das Commitment Verfahren an einem Münzwurf über das Telefon aufgezeigt. Der Münzwurf über das Telefon funktioniert nur, wenn man sicherstellen kann, dass das Gegenüber den Wert nachträglich nicht mehr ändern kann. Dies wird durch das Commitment Verfahren sichergestellt. [25] TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 20 / 62

21 Report Theoretische Grundlagen der Kryptographie Abbildung 5: Beispiele eines Münzwurfes per Telefon 1. Bob wirft die Münze und erhält ein Resultat, in diesem Fall Kopf. 2. Bob sendet ein Commitment seines Wurfs an Alice. Alice kann das Commitment nicht öffnen und somit das Ergebnis nicht einsehen. Allerdings ist nun garantiert das Bob sein Wurf nicht mehr ändern kann. 3. Alice kann ebenfalls eine Münze werfen und das Resultat ihres Wurfes Bob mitteilen. 4. Bob erhält nun das Resultat von Alice und kann danach den Schlüssel für sein Commitment an Alice senden. 5. Mit Hilfe des Schlüssels kann auch Alice prüfen, wer das Spiel gewonnen hat Berechnung eines Commitments Ein Commitment für einen Wert x kann wie folgt generiert werden. Der p-wert vom Private Key ist eine Primzahl der Form p = kq + 1. Die Werte g, h sind Elemente der Untergruppe der Ordnung q und sind beiden Teilnehmer bekannt. Zuerst wird eine Zufallszahl open x gewählt welche als Schlüssel für das Commitment verwendet wird. [25] open {0,1 } x l n Die Berechnung des Commitments basiert darauf, dass diskrete Exponentialfunktionen einfach berechnet werden können, während es aufwändig ist, die Umkehrfunktion des diskreten Logarithmus zu berechnen. c x = g x h openx (mod n) Der Sender kann das berechnete Commitment an den Empfänger übermitteln. Der Empfänger benötigt für das Öffnen des Commitments den Schlüssel open x, sowie den Wert x Homomorphes Commitment Ein Homomorphes Commitment enthält zusätzlich die Eigenschaft, dass überprüft werden kann ob die Summe der festgelegten Werte aus den einzelnen Werten besteht, ohne die einzelnen Werte in Klartext zu übertragen. Nachfolgend wird das Homomorphe Commitment am Beispiel von elektronischen Wahlen erklärt. Jeder Wähler verschlüsselt seinen Entscheid und übermittelt das berechnete Commitment an die Stimmenzähler. TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 21 / 62

22 Report Theoretische Grundlagen der Kryptographie Abbildung 6: Elektronische Wahlen Die Stimmenzähler können nun das Produkt der einzelnen Commitments berechnen, welches bei einem homomorphen Commitment dem Commitment der Summe der einzelnen Werte entspricht. E ( X )* E( Y )* E( Z) = E( X + Y + Z) Durch das Entschlüssen von E ( X + Y + Z) kann das Wahlergebnis eingesehen werden, nicht jedoch, was jeder einzelne gewählt hat. 3.4 Zero-Knowledge Proof of Knowledge Das Zero-Knowledge Proof of Knowledge kann gut anhand eines Beispiels der Höhle von Ali Baba erklärt werden. Alice möchte Bob beweisen, dass sie ein Geheimnis (eine Tür in einer Höhle öffnen kann) weiss, ohne Bob das Geheimnis zu zeigen. 1B 1. Alice läuft in die Höhle. Dafür nimmt sie einen der beiden Eingänge. Bob wartet draussen. 2. Bob begibt sich zum Eingang der Höhle und befiehlt Alice einen bestimmten Ausgang als Rückweg zu nehmen. 3. Alice beweist Bob (u.u.), dass sie im Besitz des Schlüssels der Türe ist, indem sie der Anweisung folgt. 1A 2B 3 Abbildung 7: Höhle von Ali Baba [26] Eigenschaften von Zero-Knowledge Proofs [24]: Vollständigkeit: Sofern Alice (Prover) das Geheimnis kennt, kann sie dies gegenüber Bob (Verifier) beweisen. Korrektheit/Eindeutigkeit: Es darf hingegen nicht möglich sein, dass Alice ohne Wissen des Geheimnisses einen korrekten Beweis erbringen kann. Bob (Verifier) weiss nach Anwendung des Zero-Knowledge Proofs lediglich, ob Alice das Geheimnis besitzt. Er hat allerdings nach dem Verfahren keine Kenntnisse über welches Geheimnis Alice verfügt. Um seinem Gegenüber zu beweisen, dass man über das Geheimnis verfügt, muss dieses Geheimnis in den Beweis einfliessen. Andernfalls wär es möglich, dass jeder einen korrekten Beweis erbringen könnte. Deswegen werden beim Zero-Knowledge Proof mathematische Probleme (z.b. diskrete Logarithmen) verwendet, die schwierig zu lösen sind. Damit der Verifier nicht innerhalb einer polynominalen Zeit aus dem erhaltenen Beweis das Geheimnis ermitteln kann. Ein Problem ist in Polynominalzeit lösbar, sofern die Rechenzeit m mit der Problemgrösse n nicht stärker als mit einer Polynomfunktion wächst. [24][27] TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 22 / 62

23 Report Softwarearchitektur 4 Softwarearchitektur In diesem Kapitel ist der mögliche Aufbau einer PrETP Applikation beschrieben. Dazu gehören unter anderem eine abstrakte Systemübersicht, die Komponenten- und Klassenansichten, Prozesse und Abläufe von Geschäftsprozessen innerhalb der involvierten Komponenten, die Datenstrukturen sowie die internen und externen Schnittstellen. 4.1 Systemübersicht Das Gesamtsystem besteht grundsätzlich aus drei verschiedenen Einheiten, welche untereinander wie auch mit externen Systemen interagieren. Die Abbildung 8 illustriert eine Abstraktion des Gesamtsystems. Abbildung 8: Systemübersicht Toll Service Provider (TSP): Diese Einheit stellt die staatliche Strassenverwaltung dar. Der TSP hat die Hoheit über ein bestimmtes Strassennetz. Er legt die Nutzungsbestimmungen sowie die Preise für die Benutzung des Strassennetzes fest. Der TSP kommuniziert periodisch mit den ihm unterstellten Fahrzeugen (resp. On-board Units der jeweiligen Fahrzeuge), um Abrechnungsinformationen abzurufen. Toll Charger (TC): TCs werden von den TSPs bereitgestellt, um Beweismaterial für spätere Wahrheitsprüfungen zu sammeln. Fahrzeugstandorte werden systematisch aufgezeichnet, ohne dass dabei die Erkennung eines bestimmten Bewegungsmusters oder die genaue Verfolgung des Fahrzeugs möglich ist. Ein TC generiert immer einen Nachweis, dass ein bestimmtes Fahrzeug zu einer bestimmten Zeit an einem bestimmten Ort war. Dieser Nachweis kann beispielsweise mit Hilfe eines stationären Nummernschildscanners, durch eine mobile Polizeipatrouille oder mit Hilfe von Verkehrsbussen (Parkbusse, Geschwindigkeitsübertretung) erbracht werden. Die Möglichkeiten zur Erfassung von solchen Nachweisen sind unerschöpflich. Dabei darf aber nicht vergessen werden, dass die Privatsphäre des Fahrzeughalters höchste Priorität haben muss. On-board Unit (OBU): Jedes Fahrzeug, welches sich unter der Hoheit eines bestimmten TSP s bewegt, wird mit einer OBU bestückt. Dieses Gerät ist für die GPS Lokalisierung und Wegaufzeichnung sowie für die Berechnung der Kilometerpreise zuständig. Mittels kryptographischer Protokolle werden Wahrheitsprüfungen durchgeführt, welche einen allfälligen Missbrauch der OBU aufdecken können. GPS Weginformationen werden dabei von der OBU zu TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 23 / 62

24 Report Softwarearchitektur keinem Zeitpunkt an den TSP übermittelt, es sei denn, der TSP ist ohnehin schon in Besitz eines Beweises für einen bestimmten Wegpunkt. So bleibt die Privatsphäre des Fahrzeughalters effektiv geschützt. 4.2 Komponentenübersicht Um ein besseres Verständnis der involvierten Softwarekomponenten zu erlangen, wurde die Systemübersicht in feinere, softwaretechnische Einheiten heruntergebrochen. Abbildung 9 illustriert eine aufs Wesentliche reduzierte Komponentenübersicht. Nachfolgend werden die einzelnen Komponenten genauer beschrieben. Die Spezifikation der Schnittstellen ist unter Kapitel 4.6 auf Seite 41 zu finden. tspclient common tsp.properties ITSP obu.properties ITSP tspservice obuclient tspdb IOBU obudb Abbildung 9: Komponentendiagramm Beschreibung der Komponenten tspservice: Das Kernstück des TSP s ist die Service Applikation tspservice. Als Datengrundlage bedient sich die Komponente einer dedizierten Datenbank, tspdb, welche Informationen über Fahrzeuge, Preismodelle, Karten sowie Abrechnungen bereitstellt. Die Toll Charger Komponente wird aus Zeitgründen innerhalb der Komponente tspservice realisiert. tspclient: Die Komponente tspservice wird über die GUI-Komponente tspclient gesteuert. obuclient: Die fahrzeugseitige Softwarekomponente sammelt GPS Informationen und speichert diese in die fahrzeuglokale Datenbank obudb. Zur Kommunikation mit dem TSP wird ein GSM Datenmodem verwendet. common: Es wird eine Bibliothek benötigt, welche gemeinsam verwendete Methoden, Datentypen und Interfaces anderen Komponenten zugänglich macht. In dieser common-bibliothek befinden sich nebenbei auch die Implementationen der kryptographischen Protokolle sowie der API s, welche für die Kommunikation zwischen TSP und OBU zuständig sind Kommunikation zwischen den Komponenten TSP Client TSP Service TSP Service OBU TSP DB Die Kommunikation zwischen TSP Client, TSP Service und den OBUs wird mittels XMPP realisiert. [40]. XMPP ist ein Instant Messanging Protokoll und basiert auf dem RPC-Prinzip. Zur Entkopplung der Komponenten werden Interfaces eingesetzt. Die TSP Komponente nutzt die Java Persistance API (JPA) um Informationen zwischen Domain Objects (Entity Klassen) und den Datenbank Tabellen auszutauschen. TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 24 / 62

25 Report Softwarearchitektur 4.3 Klassenübersicht Dieses Kapitel gibt einen tieferen Einblick in die eingesetzten Klassen der einzelnen Komponenten. Aus Gründen der Übersichtlichkeit werden nur die wesentlichen Klassen mit den wichtigsten Attributen und Methoden aufgeführt Klassen der Komponente tspservice Thread TSPEngine DataManager Main + main(string[]) : void «instantiate» - connector: Connector - monitor: Object = new Object() - opmodel: OPModel - pricingmodel: PricingModel - roomconn: Connection - rpc: IMRpc - secmanager: SecurityManager - userconn: Connection - initcommunication() : void + interrupt() : void + run() : void + TSPEngine() «use» - entitymanager: EntityManager - entitymanagerfactory: EntityManagerFactory - instance: DataManager - opmodel: OPModel - pricingmodel: PricingModel - DataManager() + getinstance() : DataManager + getopmodel() : OPModel + getpricingmodel() : PricingModel - initentitymanager() : void -instance model::opmodel -opmodel - challengeprovider: ChallengeProvider {readonly} - paymentprovider: PaymentProvider {readonly} - vehicleprovider: VehicleProvider {readonly} + getchallenge(integer) : Collection<ChallengeDTO> + getchallenge(integer, OPStatus) : Collection<ChallengeDTO> + getchallenges() : Collection<ChallengeDTO> + getvehicle() : Collection<VehicleDTO> + getvehiclebyid(int) : VehicleDTO + getvehiclebyregistrationnumber(string) : VehicleDTO + OPModel(EntityManager) + removevehicle(vehicledto) : void + savechallenge(challengedto) : int + savepayment(paymentdto) : int + savevehicle(vehicledto) : int + setpublickey(vehicledto) : int -pricingmodel model::pricingmodel - gpspointsprovider: GpspointProvider {readonly} - mapprovider: MapProvider {readonly} - pricingprofileprovider: PricingProfileProvider {readonly} AbstractPricingModel + getmaps(gpspointdto) : Collection<MapDTO> + getmaps() : Collection<MapDTO> + getmaps(pricingprofiledto) : Collection<MapDTO> + getpoints(mapdto) : Collection<GPSPointDTO> + getpoints() : Collection<GPSPointDTO> + getpointswithinmargin(gpspointdto, BigDecimal) : Collection<GPSPointDTO> + getpricingprofile(mapdto, Date) : PricingProfileDTO + getpricingprofiles() : Collection<PricingProfileDTO> + PricingModel(EntityManager) + savepricingprofile(collection<pricingprofiledto>) : void -vehicleprovider prov ider::vehicleprovider -challengeprovider provider::challengeprovider -paymentprovider prov ider::paymentprovider T provider::providerbase # entitymanager: EntityManager - transactioncounter: int = 0 # begintransaction() : void # committransaction() : void + createnamedquery(string) : Query + createquery(string) : Query # flush() : void # merge(t) : T # persist(t) : void + ProviderBase(EntityManager) # refresh(t) : void # refresh(collection<t>) : void # remove(t) : void # rollbacktransaction() : void -mapprovider provider::mapprovider -gpspointsprovider provider::gpspointprov ider -pricingprofileprovider provider::pricingprofileprovider Abbildung 10: Klassen der Komponente tspservice TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 25 / 62

26 Report Softwarearchitektur Main TSPEngine DataManager PricingModel OPModel *Provider ProviderBase Der Eintrittspunkt der Komponente tspservice bildet die Main Klasse, welche die Runnable-Klasse TSPEngine in einem neuen Thread startet. Die Klasse TSPEngine ist die eigentliche Service Klasse, welche die Kommunikation zum XMPP Server herstellt, die Datenbankverbindung aufbaut und die Fassadenklassen OPModel und PricingModel initialisiert. Die Singleton-Klasse DataManager initialisiert den EntityManager, welcher die JPA- Datenbankverbindung bereitstellt. PricingModel implementiert die abstrakte AbstractPricingModel Klasse aus der common Library. In dieser Klasse sind Methoden implementiert, welche die Aufrufe von Pricing Profiles, Maps und GPS Points zusammenführen. PricingModel nutzt die drei Provider-Klassen PricingprofileProvider, MapProvider, GpspointProvider für Datenzugriffe auf der Datenbank. OPModel implementiert Methoden im Zusammenhang mit den Entities Vehicle, Challenge und Payment. Die Provider-Klassen VehicleProvider, ChallengeProvider, PaymentProvider werden für Datenzugriffe genutzt. Sämtliche Provider-Klassen implementieren Zugriffsmethoden, um Entitiy Objekte der jeweiligen Typen aus der Datenbank zu lesen bzw. zu speichern. Da in diesem Projekt keine generische Umwandlung von Entity Object zu Data Transfer Object (DTO) genutzt wird, sind die Providerklassen auch für die Implementierung von entsprechenden Umwandlungsmethoden verantwortlich. Alle wichtigen Datenbank-Funktionen werden in der ProviderBase implementiert. Die Methoden werden an die Provider-Klassen weitervererbt Klassen der Komponente tspclient FormManager AddChallenge OptimisticPayment Die Klasse FormManager ist für die Kommunikation zum XMPP Server zuständig. Das heisst alle Anfrage vom tspclient an den tspservice werden über die Klasse FormManager versendet. Die Klasse AddChallenge erweitert die Java-Swing Klasse JPanel und ist somit ein Tab auf der Benutzer-Oberfläche. Über den Tab AddChallenge kann der Benutzer einen Beweis (Challenge) erfassen. Die Klasse OptimisticPayment ist ebenfalls ein Tab auf der Benutzer-Oberfläche. Über den Tab OptimisticPayment kann eine Abrechnung für ein bestimmtes Fahrzeug gestartet werden. Zudem wird das Ergebnis der Abrechnung und der während der Abrechnung geprüften Beweise angezeigt. TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 26 / 62

27 Report Softwarearchitektur Klassen der Komponente obuclient MainActiv ity Activity - logview: LogView - txtgpsposition: TextView - txtlastcharge: TextView - txtopenwaypoints: TextView - txtpaymentrecords: TextView - txtpriceperdistance: TextView - txtpricingprofile: TextView - txtservicestatus: TextView - txtxmppaddress: TextView - dobindservice() : void ~ dounbindservice() : void + oncreate(bundle) : void # ondestroy() : void «instantiate» serv ice::gpsloggerserv ice Service - connector: Connector - dbhelper: DatabaseHelper - groupparameters: GroupParameters - keypairobu: KeyPair - locationlistener: LocationListener - locationmanager: LocationManager - pricingmodel: PricingModel - publickeytsp: PublicKey - systemparameters: SystemParameters - updatemanager: UpdateManager - initcommunication() : void - initdatabase() : void - initlocationservice() : void - initsecurityparams() : void -dbhelper data::databasehelper - database: SQLiteDatabase - databasepath: String - providerlist: ArrayList<AbstractDataProvider> = null + addprovider(abstractdataprovider) : void + close() : void + createtables() : void + DatabaseHelper(Context) + droptables() : void + getprovider(class) : AbstractDataProvider + open(context) : void -activity -logview Dialog android.view.view.onclicklistener LogView - activity: MainActivity - listmessages: ListView + LogView(Context, MainActivity) serv ice::updatemanager - connector: Connector {readonly} - gpspointsprovider: GpspointProvider {readonly} - mapprovider: MapProvider {readonly} - pricingprofile2mapprovider: PricingProfile2MapProvider {readonly} - pricingprofileprovider: PricingProfileProvider {readonly} + updategpspoints() : void + UpdateManager(DatabaseHelper, Connector) + updatemaps() : void + updatepricingprofiles() : void data::mapprovider -updatemanager AbstractDataProvider data::pricingprofile2mapprovider AbstractDataProvider AbstractDataProvider data::gpspointprovider -pricingmodel serv ice::pricingmodel AbstractPricingModel - comscheme: CommitmentScheme - gpspointsprovider: GpspointProvider {readonly} - keypairobu: KeyPair - mapprovider: MapProvider {readonly} - messagelistener: MessageListener - paymentrecord2waypointprovider: PaymentRecord2WaypointProvider {readonly} - paymentrecordprovider: PaymentRecordProvider {readonly} - pricingprofileprovider: PricingProfileProvider {readonly} - publickeytsp: PublicKey - sysparams: SystemParameters - waypointprovider: WaypointProvider {readonly} - zpk: ZeroKnowledgeProof + createwaypoint(gpspointdto, double, PricingProfileDTO) : GPSPointDTO + getdistanceto(gpspointdto, GPSPointDTO, BigDecimal) : double + getmaps() : Collection<MapDTO> + getmaps(gpspointdto) : Collection<MapDTO> + getmaps(pricingprofiledto) : Collection<MapDTO> + getpaymentrecords(date) : List<PaymentRecord> + getpoints(mapdto) : Collection<GPSPointDTO> + getpoints() : Collection<GPSPointDTO> + getpointswithinmargin(gpspointdto, BigDecimal) : Collection<GPSPointDTO> + getpricingprofile(mapdto, Date) : PricingProfileDTO + getpricingprofiles() : Collection<PricingProfileDTO> + hashandsign(object) : Signature + PricingModel(DatabaseHelper) AbstractDataProvider data::pricingprofileprov ider AbstractDataProvider data::paymentrecordprov ider AbstractDataProvider data::waypointprovider AbstractDataProvider data::paymentrecord2waypointprovider Abbildung 11: Klassen der Komponente obuclient TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 27 / 62

28 Report Softwarearchitektur MainActivity LogView GPSLoggerService DatabaseHelper UpdateManager PricingManager *Provider Die MainActivity Klasse bildet den Eintrittspunkt der Android Applikation. Sie stellt ein einfaches GUI bereit, welches den Systemstatus, gegenwärtige Lokationsinformationen sowie Zahlungsinformationen ausgibt. Zu den Zahlungsinformationen gehören: Open Waypoints: Anzahl Wegpunkte und Gesamtdistanz, welche noch zu keinem Payment Record zusammengefasst wurden, also sog. Open Waypoints. Payment Records: Anzahl Payment Records (=Kilometersegmente) und Gesamtdistanz sowie Gesamtkosten, welche bereit sind für die nächste Abrechnung. Die LogView sammelt in einer ListView Debug und Log Nachrichten, welche von der Software abgefangen werden. Diese View hilft dem Betreiber bei der allfälligen Fehlersuche. Der GPSLoggerService ist das Kernstück des OBU Clients. Er wird als Android Service ausgeführt und nach dem Systemstart des Android Betriebssystems automatisch gestartet. Der Service initialisiert die Datenbankverbindung über die Klasse DatabaseHelper, verbindet das Android Gerät mit dem XMPP Server, holt sich bei der TSP aktuelle System Parameter, Karten- sowie Preisinformationen und sorgt schliesslich dafür, dass der GPS Sensor Lokationsinformationen bereitstellt. Methoden für den Datenbankzugriff auf SQLite werden in DatabaseHelper implementiert. Der UpdateManager stellt Methoden bereit, um beim TSP aktuelle Karten- und Preisinformationen herunterzuladen. Siehe auch Kapitel 5.3 Seite 46. PricingModel implementiert die abstrakte AbstractPricingModel Klasse aus der common Library. Hier werden die wichtigsten Prozesse rund um die Erfassung von Waypoints, die Segmentierung von Payment Records und den Abrechnungsvorgang implementiert. Die Provider-Klassen implementieren Methoden, um auf die SQLite Datenbank zuzugreifen. Sie stellen die Datenbankinformationen in DTO s bereit, sodass keine weitere Konvertierung nötig ist, um die Objekte zwischen OBU und TSP auszutauschen. TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 28 / 62

29 Report Softwarearchitektur Klassen in Komponente common AbstractPricing- Model Commitment- Scheme CryptoUtils HashScheme SignatureScheme ZeroKnowledge- Proof KeyPair Diese Klasse implementiert sämtliche Funktionen zur Preisberechnung, welche auf der TSP wie auch auf der OBU verwendet werden. Die implementierten Methoden müssen auf beiden Systemen identische Resultate liefern. Da TSP und OBU unterschiedliche Datenbanken unterhalten und daher den Datenzugriff unterschiedlich gestalten, werden einige Methoden abstrakt vorgegeben. Diese müssen jeweils auf TSP und OBU implementiert werden. Beispiel: public abstract getpricingprofile(map); Die Klasse CommitmentScheme enthält die Methoden commit und open. Mit der Methode commit kann ein Commitment für einen Preis berechnet werden. Als Rückgabewert erhält man das errechnete Commitment, sowie den Schlüssel (open) um das Commitment zu öffnen. Mit der open Methode wird eine Commitment geöffnet. Das heisst es wird geprüft, ob man für ein Preis, dasselbe Commitment erhält, wie das Commitment welches als Eingabeparameter mitgegeben wurde. Die Klasse CryptoUtils wurde aus dem Projekt Identity Mixer Anonymous Credential System von IBM übernommen [31]. Diese Klasse stellt die mathematischen Basisfunktionen bereit. Beispielsweise folgende: multiexpmul: berechnen eines Produktes von einem Set von modularen Potenzierung. genprime: ermitteln einer Primzahl. Diese Methoden werden in den Crypto-Klassen (CommitmentScheme, HashScheme, SignatureScheme) eingesetzt. Diese Klasse stellt eine Methode generatehash zur Verfügung welche aus einem Text einen Hash generiert. Zudem ist eine Methode verifyhash implementiert welche prüft, ob ein Hash Wert aus einem mitgegeben Text erzeugt wurde. Diese Klasse bietet zwei Methoden an. Die Methode SigSign erzeugt für einen mitgegebenen BigInteger-Wert eine CL-RSA Signatur. Diese Methode wird verwenden um die Preise der Tabelle Pricing Model zu signieren, sowie für das Signieren von Hash-Werten welche über das Kommunikationsprotokoll übertragen werden. Die Methode SigVerify erlaubt, dass geprüft werden kann, ob eine Signatur zu einem bestimmten BigInteger-Wert gehört und ob der BigInteger-Wert mit dem erwarteten Schlüssel signiert wurde. Diese Klasse enthält die Methoden computeproof um eine Proof zu erstellen und verifyproof um einen Proof zu prüfen. Das ZeroKnowledgeProof Verfahren wird verwendet, um zu prüfen, dass die OBU korrekte Preise verwendet. Das heisst die OBU darf nur Preise verwenden, welche von der TSP signiert wurden. Es sollte aber für die TSP nicht möglich sein, anhand eines Empfangen Proofs die Signatur herzuleiten. Denn dadurch wüsste die OBU welcher Preis für diesen Abschnitt verwendet wurde. Die Klasse KeyPair erzeugt beim Erstellen einer Instanz ein Schlüsselpaar bestehend aus Public Key und Private Key. TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 29 / 62

30 Report Softwarearchitektur 4.4 Prozesse und Abläufe Die nachfolgenden Grafiken visualisieren die als Use Cases erfassten Geschäftsprozesse, welche vom Projektsystem unterstützt werden müssen. Die Referenznummern der Abbildungen korrespondieren mit der im Anschluss gegebenen Erklärungstabellen. Die verwendeten Formeln stammen teilweise aus [7] TSP-seitige Prozesse Die nachfolgend illustrierten Abläufe umfassen beide Komponenten, TSP Client und TSP Service. Der TSP Client agiert als Initiator von Prozessen während TSP Service auf Befehle wartet und Rückmeldungen verarbeitet. Besonders nennenswerte Aktionen werden im Anschluss an die Abbildung 12 detaillierter erklärt. Abbildung 12: Zustandsdiagramm der Prozesse seitens OBU TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 30 / 62

31 Report Softwarearchitektur Initialisierung des Security Managers 1.1 Der Security Manager ist zuständig für das Einlesen der System Parameter. Diese beinhalten vor allem Schlüssellängen und andere statische Parameter. Zudem wird das Schlüsselpaar für den TSP generiert, welches aus einem Privat und Public Key besteht. 1.2 Beim Initialisieren wird auch geprüft, ob es Pricing Profiles gibt, welche zum Preis noch keine gültige Signatur erhalten haben. Bei Bedarf wird diese erstellt und in die Datenbank geschrieben. Group Parameters für OBU generieren 2.1 Ein Schritt der Initialisierungsphase von OBUs beinhaltet das Anfragen von Group Parameters (g 0, g 1 ) beim TSP Service. Auf solche Anfragen reagiert der TSP Service, indem er für die anfragende OBU neue Group Parameters generiert (sofern diese nicht bereits existieren). 2.2 Diese neuen Group Parameters werden in der TSPDB dem entsprechenden Fahrzeug hinterlegt. 2.3 Schliesslich werden die Group Parameters als Rückmeldung an die anfragende OBU gesendet. Optimistic Payment Anfrage lancieren 3.1 Auf dem TSP Client wird ein Fahrzeug ausgewählt, für welches der Optimistic Payment Prozess gestartet wird. 3.2 Als nächstes wird das Enddatum der Abrechnungsperiode festgelegt. Dieses Enddatum bestimmt, welche der auf der OBU gespeicherten Payment Records in die Abrechnung einbezogen werden. Um zu vermeiden, dass einige Payment Records nie abgerechnet werden, kann kein Anfangsdatum gesetzt werden. 3.3 Sofern die angefragte OBU irgendwelche Payment Records übermitteln kann, werden diese Records an Verifikationsfunktionen weitergereicht. Ansonsten wird der Optimistic Payment Prozess an dieser Stelle beendet. TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 31 / 62

32 Report Softwarearchitektur 3.4 Die Verifikation der zurückgegebenen Payment Records umfasst zwei wesentliche Schritte: Prüfung des Zero-Knowledge Proofs. Für alle Payment Records wird geprüft, ob die korrekte Preissignaturen und somit die korrekten Preise verwendet wurden. Dadurch wird verhindert, dass auf der OBU falsche Preise im Negativenbereich gewählt werden können, welche den Totalpreis verringern würden. Anschliessend wird das Produkt der einzelnen Commitments c pk aus den Payment Records berechnet und mit dem geöffneten Commitment der Summe fee verglichen. Hier wird geprüft, ob sich die von der OBU mitgeteilte Totalsumme fee aus den Teilsummen der Payment Records zusammensetzt. 4 Proof-Challenge Phase 4.1 Als nächstes wird geprüft, ob das Fahrzeug, welches soeben mit Optimistic Payment abgerechnet wurde, in der Abrechnungsperiode Challenges vorliegen. 4.2 Sofern Challenges existieren, werden diese sequentiell an jene OBU gesendet, welche soeben den Optimistic Payment Prozess durchlaufen hat. 4.3 Die Antworten werden von TSP Service ausgewertet (Kapitel 4.4.3, Seite 36) und in der Datenbank zur Weiterverarbeitung durch das TSP Personal gespeichert. TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 32 / 62

33 Report Softwarearchitektur OBU-seitige Prozesse Abbildung 13 illustriert die Prozesse, welche auf der OBU implementiert werden. Besonders nennenswerte Aktionen werden anschliessend detaillierter erklärt. OBU launched oncreate Already configured? Yes Initialize Database No Create Database Schema Get System Parameters and Public Key from TSP 1.1 Search Map to which received GPS Point belongs Initialize Communication Get GroupParameters from TSP 1.2 Calculate Distance to last Waypoint Update Pricing and Map Information Generate KeyPair 1.3 Store new GPS Waypoint to Database Initialize Location Service Send Public Key to TSP 2.1 Sum(OpenWaypoints) > 1km? No OBU running Update Pricing and Map Information Calculate Hash of (GPSPoint, Date) 2.4 Calculate Commitment for the Price in Payment Table 2.5 Yes Calculate Price for given GPS Point Generate a Proof for the Price in Payment Table ondestroy Disconnect Get new Group Parameters from TSP Calculate Total Fee Calculate Commitment for Total Fee Send Payment response to TSP Store new Payment Record to Database Check Challenges and send Responses to TSP 3.5 OBU shut down Delete Payment Records 3.6 Abbildung 13: Zustandsdiagramm der Prozesse seitens OBU TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 33 / 62

34 Report Softwarearchitektur Neuer Wegpunkt festhalten 1.1 Finde die Map, zu welcher der aufgezeichnete GPS Punkt passt. 1.2 Berechne die Distanz vom aufgezeichneten GPS Punkt zum letzten festgehaltenen GPS Punkt. 1.3 Speichere den neuen GPS Wegpunkt zusammen mit der berechneten Distanz in die Datenbank. Neuer Payment Record erzeugen 2.1 Falls die Gesamtdistanz der offnen Wegpunkten eine bestimmte Distanz (=Länge eines Abrechnungssegments, z.b. 1km) überschreitet, so wird ein neuer Payment Record angelegt. 2.2 Für jeden neuen Payment Record muss der aktuelle Zonentarif bestimmt werden. Dafür steht eine Methode bereit, welche für einen gegebenen GPS Punkt loc k die entsprechende Map findet und mit gegebenem Zeitstempel time k herausfindet, welcher Zonentarif p k verrechnet werden muss. (Siehe auch Kapitel 5.2 Preisberechnungsfunktion, Seite 43). 2.3 Für jeden Payment Record wird ein Hash generiert. Der Inputwert für den Hash ist ein String bestehend aus dem aufgezeichneten GPS Punkt loc k und dem Zeitpunkt time k an welchem der GPS Punkt aufgezeichnet wurde. 2.4 Für den gewählten Preis wird ein kryptographisches Commitment berechnet. 2.5 Anschliessend wird mit Hilfe der Preissignatur, dem Public Key von TSP sowie den Group Parameters ein non-interactive Zero-Knowledge Proof of Signature Posession berechnet. Beim Zero-Knowledge Proof geht es darum, dem gegenüber zu Beweisen, dass man über eine Geheimnis verfügt, in diesem Fall die Signature des Preises kennt, ohne dem Gegegenüber die Signaur offen zu legen. (Siehe Kapitel 3.4 Zero-Knowledge Proof of Knowledge, Seite 22). 2.6 Speichere den neuen Payment Record in die Datenbank und assoziere diesen mit den dazugehörigen Teilstrecken, welche in Form von GPS Wegpunkten aufgezeichnet wurden. TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 34 / 62

35 Report Softwarearchitektur Optimistic Payment Prozess starten 3.1 Die OBU bezieht neue Group Parameters (g 0, g 1 ), welche für die Berechnung von neuen Payment Records verwendet werden. 3.2 Berechne aus den Preisen p k der einzelnen Payment Records die Totalsumme fee. 3.3 Durch das Summieren der einzelnen Schlüssel (open) für die Commitments erhält man den Schlüssel um das Commitment der Totalsumme zu öffnen. 3.4 Die berechneten Werte fee und open fee werden zusammen mit den Payment Records bestehend aus Hash h k, Commitment c pk und Proof π in einer Nachricht m zusammengefasst. Diese Nachricht wird zusammen mit der signierten Nachricht an den TSP übertragen. 3.5 Nach erfolgtem Payment Prozess wartet die OBU auf Challenges vom TSP. Ein Challenge ist ein formeller Nachweis, dass ein Fahrzeug zu einer bestimmten Zeit an einem bestimmten Ort gewesen sein muss. Der Challenge Datentyp beinhaltet deshalb die Position (Longitude, Latitude) sowie ein Zeitstempel. Die OBU muss den Challenge bestätigen können. (Siehe Kapitel 4.4.3, Seite 36). 3.6 Wenn alle Challenges abgearbeitet wurden, kann die OBU sämtliche bereits abgerechnete Payment Records und dazugehörige GPS Wegpunkte aus der Datenbank löschen. Es dürfen aber keineswegs Payment Records oder GPS Wegpunkte gelöscht werden, welche noch nicht abgerechnet wurden! TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 35 / 62

36 Report Softwarearchitektur Interaktion zwischen TSP und OBU: Proof-Challenge Das Proof-Challenge Verfahren beschreibt jenen Prozess, welcher direkt nach dem Optimistic Payment Prozess ausgeführt wird. Nach dem Optimistic Payment Prozess besitzt der TSP genügend Informationen, um die durch die TCs während der vergangenen Abrechnungsperiode aufgezeichneten Spot Checks zu verifizieren. Abbildung 14: Ablauf Proof Challenge um Datenmanipulationen aufzudecken. TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 36 / 62

37 Report Softwarearchitektur Response für Proof erstellen Die OBU verifiziert die in der Challenge Nachricht vorgefundene Signatur mit Hilfe des Public Keys von TSP und prüft damit, ob die Nachricht tatsächlich vom TSP stammt. Danach wird in der Tabelle der GPS Wegpunkte nach demjenigen GPS Punkt gesucht, welcher bestmöglich mit der im Challenge vorgefungenen Position (Longitude, Latitude) sowie dem Zeitstempel übereinstimmt. Bei der Suche wird sowohl beim gesuchten GPS Punkt wie auch beim gesuchten Zeitstempel eine bestimmte Marge 2 zugelassen. Findet die OBU einen Punkt, der in unmittelbarer Nähe der Challenge Lokation und zur gegebenen Zeit aufgezeichnet wurde, so sucht die OBU den Payment Record, über welchen dieser GPS Punkt abgerechnet wurde. Anhand des Payment Records kann die OBU herausfinden, welcher GPS Punkt für die Preisberechnung massgebend war. 3 Die Response-Nachricht setzt sich aus einer Identifikation, der gesuchten Lokation, dem verrechneten Preis sowie der kryptographischen Öffnung für das Commitment des Preises zusammen: r = (id, location k, time k, p k, open k ) Die Nachricht wird signiert und zurück an TSP gesendet. Damit ist die Arbeit für die OBU getan. Kann die OBU für einen Challenge kein passender Payment Record finden, so kann die Anfrage nicht beantwortet werden. Dieses Verhalten hilft einerseits Missbrauch aufzudecken, schützt aber auch die OBU vor missbräuchlichen Challenge Requests, ausgehend von TSP. Der TSP verifiziert die in der Response-Nachricht vorgefundene Signatur mit Hilfe des Public Keys der involvierten OBU. Response verifizieren Zuerst prüft der TSP, ob die mit der Response-Nachricht empfangenen Lokations- und Zeitinformationen mit bereits abgerechneten Informationen übereinstimmt. Dazu berechnet der TSP ein Hash von Longitude, Latitude und Zeit: h = H(longitude, latitude, time) Falls der Vergleich erfolgreich ist, weiss der TSP, dass die OBU zu diesem Zeitpunkt keine falschen Lokationsinformationen aufgezeichnet hat. Als nächstes verifiziert der TSP, ob das Preise-Commitment der Response-Nachricht mit einem während der letzten Abrechnungsperiode empfangenen Preis-Commitments übereinstimmt. pk open c pk = g 0 * g 0 mod n p k : Preis deklariert in Response open: Kryptographische Öffnung für das Commitment des Preises p k c pk : Während Optimistic Payment empfangenes Commitment auf Preis p k c pk = c pk? Falls der Vergleich erfolgreich ist, weiss der TSP, dass die OBU für das geprüfte Zonensegment denselben Preis verrechnet hat, wie sie in der Response mitgeteilt hat. 2 Die Marge muss konfigurierbar sein. 3 In diesem System wird der letzte GPS Punkt eines Payment Records verwendet, um den Zonentarif zu bestimmen. Siehe Kapitel 5.2 Preisberechnungsfunktion, Seite 44. TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 37 / 62

38 Report Softwarearchitektur Danach berechnet der TSP den Preis für die empfangene Lokations- und Zeitinformationen anhand der verbindlichen Preisfunktion und prüft, ob das Commitment des Preises denselben Wert ergibt, wie jenes, welches während der letzten Abrechnungsperiode empfangen wurde. p = f(location k, time k ) c pk = g p open 0 *g 0 mod n c pk = c pk Falls der Vergleich erfolgreich ist, weiss der TSP, dass die OBU für die Berechnung des Preises die korrekte Preisfunktion verwendet hatte. Abschliessend werden die Ergebnisse der Verifikation in die Datenbank gespeichert, sodass sie von TSP Clients eingesehen werden können. TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 38 / 62

39 Report Softwarearchitektur 4.5 Datenstrukturen Das PrETP System besteht aus zwei voneinander unabhängigen, verteilten Datenbanken. Die eine Datenbank, nachfolgend TSPDB genannt, dient als Datengrundlage für den Toll Service Provider. Darin werden die verwalteten Fahrzeuge (resp. deren OBUs) sowie die vom TC bereitgestellten Challenges gespeichert. Das zweite Datenbankschema kommt auf den OBU Clients zum Einsatz. Nachfolgend werden beide Schemas visualisiert und spezifiziert TSPDB Abbildung 15: Physisches Entity-Relationship-Modell der TSP Datenbank Vehicle Payment Challenge Diese Tabelle beinhaltet sämtliche fahrzeugspezifischen Informationen, welche zum Betrieb der TSP notwendig sind. Der Primärschlüssel (vehicleid) ist rein technischer Natur. Die effektive Kennzeichennummer eines Fahrzeugs wird hingegen im Feld registrationnumber abgespeichert. Um die OBU eines Fahrzeugs zu kontaktieren, muss eine gültige Adresse (address) existieren. Das implementierte Kommunikationskonzept mit XMPP basiert auf Adressen im Format von Adressen. Deshalb besteht anders als bei IP-basierten Konzepten kein Bedarf zur permanenten Aktualisierung der OBU Adresse. Die Payment Tabelle führt Journal über die Zahlungen, welche für ein Fahrzeug ausgelöst wurden. Zu jedem Fahrzeug können beliebig viele Zahlungen eingetragen werden. Der Zeitraum wird jeweils mit periodfrom und periodto beschränkt. Der verrechnete Betrag wird im Feld fee gespeichert. Schliesslich besitzt jede Abrechnung auch einen Status. In der Challenge Tabelle werden alle durch TCs festgehaltenen Challenges abgelegt. Grundsätzlich besteht ein Challenge aus einem Zeitstempel (time) und der Positionsinformation (latitude, longitude). TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 39 / 62

40 Report Softwarearchitektur Gemeinsame Datenstruktur Die Datenstruktur für Preis- und Karteninformationen ist auf TSP wie auf OBU dieselbe. Abbildung 16 zeigt die Datenstruktur, welche auf TSP und OBU identisch implementiert ist. Abbildung 16: Physisches Entity-Relationship-Modell, welches von TSP und OBU genutzt wird Pricingprofile Map Gpspoint Die Tabelle Pricingprofile wiederspiegelt das Preismodell, welches vom TSP vorgegeben wird. Jedes Profil hat eine datierte Gültigkeit (validfrom, validto) und findet zu einer bestimmten Uhrzeit (timespanfrom, timespanto) Anwendung. Die Preisfelder priceperdistance und priceperentry enthalten Rappenpreise für eine gefahrene Abschnittslänge (z.b. 1km) respektive für das Eintreten in eine bestimmte Zone (z.b. Stadtzentrum). Die Map Tabelle speichert verschiedene Kartenausschnitte, zu welchen Preisinformationen hinzugefügt werden können. Jede Map besteht aus mindestens drei Punkten. Die Gpspoint Tabelle speichert die Koordinaten, welche eine Map definieren OBUDB In Abbildung 17 wird die Datenstruktur der OBUDB gezeigt. Abbildung 17: Physisches Entity-Relationship-Modell der OBU Datenbank Waypoint PaymentRecord Die Tabelle Waypoint dient zur Aufzeichnung von Positionsinformationen, welche aus dem GPS Sensor des Mobile Devices ausgelesen werden. In die Tabelle PaymentRecord wird ein Eintrag geschrieben, sobald die Summe der offenen GPS Wegpunkte (sog. Open Waypoints ) grösser oder gleich der definierten Segmentlänge (z.b. 1km) ist. Sie enthält auch je ein Feld für den kryptographischen Proof, das Commitment auf den Preis sowie den Hash von Lokation+Zeit. TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 40 / 62

41 Report Softwarearchitektur 4.6 Spezifikation der Schnittstellen Interne Schnittstellen Interface Methodensignatur & Beschreibung IOBU ITSP charge(date latestdate) Mit dieser Methode kann der TSP einen Abrechnungsprozess auf der OBU anstossen. In der Abrechnung werden alle aufgezeichneten Strecken bis zum Enddatum berücksichtigt. challenge(arraylist<challengedto> challenges) Mit dieser Methode kann der TSP mehrere Beweise (Challenges) an eine OBU senden. Die OBU wird anhand der aufgezeichneten Strecken versuchen, die Beweise zu beantworten. getmaps() Mit getmaps kann die OBU die aktuellen Maps (Kartenausschnitte) beim TSP anfordern. Eine Map ist eine fix abgesteckte Zone, welche zur Tarifbestimmung genutzt wird. getgpspoints() Mit diesem Aufruf erhält man die Begrenzungspunkte der Maps. getpricingprofiles() Mit dieser Methode kann die OBU beim TSP die aktuellen Preispläne anfordern. getsystemparameters() Um die System Parameter, welche beispielsweise die Schlüssellängen enthalten, bei der TSP abzufragen getgroupparameters(arraylist<vehicledto> vehicle) Hiermit können die Group Parameter (g 0, g 1 ) bei der TSP für ein spezifisches Fahrzeug abgefragt werden. getpublickeytsp() Damit kann die OBU den Public Key des TSP in Erfahrung bringen. setpublickeyobu(arraylist<vehicledto> vehicle) Hiermit kann die OBU ihren Public Key dem TSP mitteilen. addchallenge(arraylist<challengedto> dto) Dadurch wird ein Beweis (Challenge) in der Datenbank gespeichert. getvehicles() Mit diesem Aufruf können alle registrierten Fahrzeuge abgefragt werden. initpayment(integer vehicleid, Date enddate) Mit diesem Aufruf kann der TSP Client ein Abrechnungsprozess für das angegeben Fahrzeug bei der TSP starten. In der Abrechnung werden alle aufgezeichneten Strecken bis zum Enddatum berücksichtigt Externe Schnittstellen Schnittstellen zu Umsystemen sind in diesem Projekt keine vorgesehen. Das System wurde aber so gestaltet, dass eine Anbindung an ein bestehendes Fahrzeugverwaltungssystem möglich wäre. TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 41 / 62

42 Report Design-Entscheide 5 Design-Entscheide In diesem Kapitel sind verschiedene Design-Entscheide dokumentiert. Das Ziel dieses Kapitel ist es, aufzuzeigen, aus welchen Gründen und mit welchen Überlegungen ein bestimmter Design-spezifischer Entscheid getroffen wurde. 5.1 GPS Lokalisierung Das Erfassen von Lokationsinformationen über GPS ist eine der Hauptaufgaben der OBU. Bei diesem Vorgang spielen Umwelteinflüsse eine entscheidende Rolle. Nicht überall ist eine genügende Signalstärke verfügbar, um einen brauchbaren GPS Fix 4 zu erlangen. Tunnel, Verbauungen, Wetterbedingungen und Fahrgeschwindigkeit können die Präzision der Positionierung beeinflussen. Die OBU muss sich diesen Gegebenheiten bestmöglich anpassen. Die Android Location API bietet verschiedene Konfigurationsparameter, um das Ausleseverhalten des GPS Sensors zu steuern. Die beiden wichtigsten Parameter, mintime und mindistance, werden abhängig von der aktuellen Fahrgeschwindigkeit mit einer einfachen linearen Funktion ermittelt: Formel zur Berechnung von mintime: mintime=f(speed)=abs(speed*500)+5000 Formel zur Berechnung von mindistance: mindistance=f(speed)=abs(speed*5)+50 Abbildung 18: Funktionsgraph zur Berechnung des mintime Parameters. Abbildung 19: Funktionsgraph zur Berechnung des mindistance Parameters. Ein Zahlenbeispiel: Fährt ein Fahrzeug mit der Geschwindigkeit v=50km/h=13.8m/s, so wird der GPS Sensor mindestens alle 11.9s oder 119m neu ausgelesen. Massgebend ist ersteintreffendes Ereignis. Die Vorteile eines guten Algorithmus liegen nicht nur in Erhöhung der Messgenauigkeit und somit der Fairness gegenüber dem bezahlenden Anwender zu finden es muss auch bedacht werden, dass das Anlegen von GPS Waypoints und den damit verbundenen Payment Records einen gewissen Overhead verursachen. Je feingranularer die GPS Aufzeichnungen, umso mehr Speicherplatz und CPU Ressourcen werden beansprucht. 4 Als GPS Fix bezeichnet man das Feststellen einer GPS Position mit Hilfe von mehreren GPS Satelliten. TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 42 / 62

43 Report Design-Entscheide 5.2 Preisberechnungsfunktion Eine zentrale Frage in diesem Projekt dreht sich um die Berechnung der Kilometerleistung. Jede aufgezeichnete Wegstrecke muss unter Berücksichtigung der aktuell geltenden Preismodelle verrechnet werden. Damit das vorliegende Projektsystem funktioniert, müssen die Strassenkarten in Zonen eingeteilt werden. (Der Begriff Zone wird je nach Kontext in diesem Dokument abwechselnd mit Tarifzone, Karte oder Map genutzt). Dabei handelt es sich um fix abgesteckte, geographische Zonen, welche zur Tarifbestimmung genutzt werden. Abbildung 20: Kartenausschnitt von Horw (LU) mit vier Tarifzonen. Jede Zone ist einem Preismodell zugeordnet. Über dieses Preismodell kann beispielsweise festgelegt werden, welcher Tarif pro Distanz abhängig von der aktuellen Uhrzeit verrechnet werden muss. Die Gültigkeit von Preismodellen kann vom TSP definiert werden. Hinweis für Weiterentwicklung Als zusätzliche Attribute für die Verrechnung in Preismodellen könnten die Ein- und Ausfahrt in resp. aus Zonen dienen. Solche Modelle sind heute schon Praxis, wie das Beispiel der Stockholmer Innenstadt zeigt. (Siehe [10]). Des Weiteren könnten zur Preisbestimmung auch demographische oder fahrzeugspezifische Merkmale beigezogen werden. TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 43 / 62

44 Report Design-Entscheide Um von einem aufgezeichneten GPS Punkt zum berechneten Preis zu gelangen sind folgende Schritte notwendig: 1. Distanz zwischen zwei Punkten berechnen Die Berechnung der Distanz zweier Punkte auf einer Ebene ist mit einfachen mathematischen Methoden möglich. Die Distanz zwischen GPS Punkten auf der Erde ist jedoch eine diffizilere Angelegenheit. In der Fachsprache wird diese Distanz als Orthodrome bezeichnet [11]. Bei der Berechnung von GPS Distanzen auf der Erdoberfläche muss die ellipsoide Form der Erde mitberücksichtigt werden. Die Location Klasse von Android implementiert bereits hilfreiche Funktionen wie distancebetween(location a, Location b). So wird beim Feststellen eines neuen GPS Punkts jeweils eine Distanzberechnung zum letzten aufgezeichneten Punkt vorgenommen. Falls dieser nicht existiert (z.b. nach einem Neustart der OBU), wird der letzte GPS Punkt aus der Datenbank gelesen. Falls in der Datenbank ebenfalls kein GPS Punkt vorhanden ist (z.b. bei der ersten Inbetriebnahme oder nach dem Abrechnungsvorgang), so wird mit dem Berechnen der Distanz bis zum nächsten GPS Punkt abgewartet. 2. Kartenzugehörigkeit des gegebenen Punktes bestimmen Sobald ein neuer GPS Punkt bekannt ist, muss dessen Zugehörigkeit zur Preiszone bestimmt werden. Das Problem bei dieser Aufgabe ist wie folgt: Finde aus einer Menge GPS-abgegrenzter Polygonen, jenes Polygon, welches den gegebenen GPS Punkt einschliesst. Das mathematische Problem wird in der Fachsprache als Point-Location Problem bezeichnet. Hinweis für Weiterentwicklung Es gibt bereits verschiedene Suchalgorithmen, um Point-Location Probleme zu lösen. Eines der gängigsten und effizientesten Verfahren implementiert einen KD Search Tree. Algortihmen dieser Art sind in Software Libraries verfügbar (z.b. im Open Source Projekt Computational Geometry Algorithms Library (CGAL; siehe[12]). Des Weiteren könnten solche Probleme direkt in der Datenbank gelöst werden. Gängige Datenbanksysteme stellen sog. spatiale Datentypen (z.b. POINT, LINE oder POLYGON) zur Verfügung. Auch für die auf Android eingesetzte SQLite Datenbank gibt es eine Erweiterung mit spaitalen Datentypen. Eine produktive Umsetzung dieses PrETP-Systems würde sicherlich auf eine Lösung in diesem Rahmen zurückgreifen. Aus zeitlichen Gründen wurde auf die Implementation eines aufwändigen Geometrie-Algorithmus verzichtet. Stattdessen wurde ein eigener, sehr primitiver Suchalgorithmus entworfen, welcher mit geschickter Parametrisierung eine akzeptable Suchleistung bringt. Der vorgeschlagene Suchalgorithmus operiert in wenigen, nachvollziehbaren Schritten. Als Eingabewert wird ein beliebiger Punkt (roter Punkt) gewählt. Zuerst wird ein quadratischer Suchraum konfiguriert, dessen halbe Länge genau dem Parameter searchmargin entspricht. Danach werden alle Maps gesucht, deren Abgrenzungspunkte innerhalb des spezifizierten Latitudeund Longitude-Intervalls liegen. (Im Beispiel von Abbildung 21 wird der Punkt { , } als Abgrenzungspunkt zwischen der gelben und der roten Tarifzone gefunden). Abschliessend kann geprüft werden, ob der gegebene Punkt in einem der gefunden Kartenausschnitte liegt. Für diese Aufgabe wird der Winding Number Algorithmus verwendet [13]. Ausgehend vom gegebenen Punkt wird eine Winkelsumme aller Vektoren, welche sich zwischen dem gegebenen Punkt und den abgrenzenden Punkten des Polygons befinden, berechnet. (Im vorliegenden Fall wäre das Resultat für die gelbe Fläche positiv). TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 44 / 62

45 Report Design-Entscheide Abbildung 21: Eingrenzung des Suchraums 3. Zonentarif für Map abfragen Als letztes muss nun für den gefundenen Kartenausschnitt das passende Preisprofil gesucht werden. Diese Aufgabe wird mit einer einfachen Datenbank Join-Query bewerkstelligt. 4. Zonentarif mit Distanz verrechnen Grundsätzlich gibt es verschiedene Möglichkeiten, die aufgezeichneten Wegstücke mit einem Tarif zu verrechnen. Nachfolgend werden zwei in Frage kommende Varianten gegeneinander abgeschätzt: Variante 1 Variante 2 Beschreibung Der Tarif wird beim Feststellen einer neuen GPS Koordinate (onlocationchanged) mit dem entsprechenden Tarif verrechnet. Die Verrechnungsintervalle variieren, abhängig vom konfigurierten Aufzeichnungsintervall des GPS Sensors. Der Tarif wird nach einer fix definierten Distanz abgerechnet (z.b. nach 1km). GPS Wegpunkte werden aufgezeichnet bis die besagte Marke erreicht wird. Der letzte Punkt dieser Distanz wird zur Bestimmung der Tarifzone verwendet. Vorteile Einfache Implementierung der Datenstruktur seitens OBU. Einfaches Prinzip. Erlaubt Proof-Challanges und Preis- Commitments. TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 45 / 62

46 Report Design-Entscheide Nachteile Neben Commitment auf Preis auch Commitment auf Distanz nötig. Tabelle 8: Vergleich der Varianten zur Berechnung des Kilometertarifs Kann zu unfairen Situationen führen. 5 Messfehler werden in Kauf genommen. 6 Variante 1 wird in diesem Projekt nicht weiterverfolgt. Ein Toll Charger müsste in Variante 1 als Nachweis nicht nur Kennzeichennummer, Zeit und Ort erfassen; es müsste auch die aufgezeichnete Distanz zwischen zwei aufeinanderfolgenden Toll Charger mitberücksichtigt werden. Ansonsten könnten die Distanzinformationen manipuliert werden, während die Preisinformationen korrekt sind. 5.3 Updates von Karten- und Preisinformationen Karten- und Preismodelle werden vom TSP vorgegeben. (Siehe dazu auch das Kapitel Datenstrukturen, im Speziellen Kapitel 4.5.1, Seite 39). Es wird angenommen, dass die Modelle nicht täglich ändern, sondern Monate wenn nicht Jahre im Voraus definiert und für die OBUs zum Download bereitgestellt werden. Das Pull-Prinzip, nach welchem die OBU sich die aktuellen Daten beschafft, wird nach folgender Logik implementiert: Eine unkonfigurierte OBU holt sich die aktuellen Karten- und Preisinformationen bei der ersten Inbetriebnahme. Danach werden die Daten vor jeden Payment Request aktualisiert und es wird geprüft, ob die Payment Records (h k, c pk, π) mit korrekten Preisplänen berechnet wurden. Mit den korrekten Preisplänen ist gemeint, dass die Preispläne verwendet wurden, welche zu diesem Zeitpunkt gültig waren. Sind Payment Records enthalten die mit veralteten Preisplänen berechnet wurden, so müssen diese Payment Records erneut generiert werden. Diese Funktionalität ist vom vorliegenden Prototyp nicht implementiert. Mit diesem Algorithmus ist es möglich, dass eine OBU ggf. keine aktuellen Preis- und Karteninformationen mehr besitzt während die Aufzeichnung von Lokationsdaten fortgesetzt werden kann. Spätestens vor dem eigentlichen Abrechnungsvorgang muss die OBU das genaue Preismodell kennen. Hinweis für Weiterentwicklung Elegant wäre die Übermittlung von Karten-/Preisinformationen über einen Broadcast Mechanismus. Das eingesetzte Kommunikationsprotokoll XMPP würde sog. Chat Rooms bereitstellen, an welchen sich die OBUs anmelden könnten. Alle Room User würden dabei gleichzeitig mit neusten Informationen versorgt (Push-Prinzip). 5 Angenommen, ein Fahrzeug zeichnet in einer preisgünstigen Zone 9 Wegstücke à 100m auf, fährt dann in eine teurere Zone und komplettiert dort das 1km-Verrechnungswegstück. In diesem Fall wird im Prinzip zu viel verrechnet. Die umgekehrte Fahrweise (von teure in günstige Zone fahren) kompensiert diesen Nachteil jedoch. 6 Angenommen, ein Fahrzeug registriert alle 100m einen GPS Wegpunkt. Sobald das Fahrzeug die 1km Marke überschreitet, wird ein 1km-Tupel verrechnet. Die überschüssigen Meter werden zugunsten des Fahrzeugnutzers abgerundet. TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 46 / 62

47 Report Design-Entscheide 5.4 Umsetzung des Proof-Challenge Verfahrens Das vorgeschlagene PrETP-System versucht, Fälle von manipulierten Abrechnungsinformationen durch ein Verfahren ähnlich wie Challenge-Response aufzudecken. Die mathematischen Grundlagen zu diesem sogenannten Proof-Challenge Verfahren werden bereits in Kapitel 4.4.3, Seite 36 eingehend erklärt. Über die praktische Umsetzung wird in diesem Kapitel diskutiert. Jeder Challenge Request beinhaltet ein oder mehrere Proofs, d.h. Nachweise, dass sich ein Fahrzeug zu einem bestimmten Zeitpunkt an einem bestimmten Ort aufgehalten haben muss. Die OBU hat die Aufgabe, für jeden Challenge eine zufriedenstellende Antwort (Response) zu liefern. Kann Sie dies nicht, so muss davon ausgegangen werden, dass die Daten der OBU nicht mit jenen des Proofs übereinstimmen. 1. GPS Wegpunkt für Challenge finden Bei Erhalt der Challenges sucht die OBU für jeden {location, time}-tupel einen passenden Datensatz in der Waypoint Tabelle. Dabei geht sie wie folgt vor: Suche einen Punkt in Tabelle Waypoint, welcher dem gegeben Zeitnachweis time am nächsten kommt 7. Eine einfaches SQL Query kann diese Suchanfrage befriedigen: SELECT * FROM waypoint ORDER BY ABS(time gmttimestamp) ASC LIMIT 1; Vorsicht: Die Differenz des Zeitstempels kann auch negativ sein. Deshalb müssen hier zwingend absolute Werte verglichen werden. Prüfe, ob der gefundene Wegpunkt innerhalb der vom TSP vorgegebenen maximalen Distanz- und Zeitmarge liegt. Falls dies nicht der Fall ist, kann die Challenge nicht beantwortet werden. Ansonsten wird der gefundene GPS Wegpunkt 2. Signifikanter Abrechnungspunkt finden Nachdem ein Wegpunkt gefunden wurde, welcher in innerhalb der vorgegebenen Margen liegt, wird der signifikante Abrechnungspunkt gesucht. Dieser Punkt, der abschliessende eines Payment Records, wurde zur Berechnung des Preises verwendet. Um das Commitment zu bestätigten, muss dieser signifikante Punkt von der OBU als Antwort auf die Challenge zurückgegeben werden. 3. Antwort auf Challenge prüfen Der TSP wertet danach die erhaltenen Responses aus. Dazu geht er wie folgt vor: Vorgängig werden die in der Challenge gegebenen Zeit- und Lokationsinformationen mit den empfangenen Zeit- und Lokationsinformationen verglichen. Liegen die erhaltenen Werte innerhalb der vorgegebenen Margen 8, so kann die Challenge-Response weiterbearbeitet werden. Ansonsten wird die Antwort als ungültig markiert. TSP sucht in der Datenbank nach einem Hash-Wert, welcher mit dem Hash der empfangenen Lokations- und Zeitinformationen übereinstimmt. Preis-Commitment mit zurückgegebener Opening und Preis berechnen und mit existierendem Commitment vergleichen. Anhand der Preisfunktion prüfen, ob TSP denselben Preis verrechnen würde, wie OBU verrechnet hat. 7 Hier wird sofort klar, warum das Thema Zeitsynchronisation (insbesondere zwischen TC und OBU) elementar wichtig ist. Siehe Kapitel 7.3.5, Seite Vorsicht: Die OBUs rechnen die aufgezeichneten GPS Wegpunkte erst nach Vervollständigung des Payment Records ab, beispielsweise nach 1km. Theoretisch wäre es also möglich, dass OBUs sogar erst nach 1.5km oder mehr (je nach Messintervall) einen Payment Record abschliessen können. Das muss bei der Bemessung der Marge berücksichtigt werden. TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 47 / 62

48 Report Design-Entscheide 5.5 Persistenz Die nachfolgenden Abschnitte beschreiben, wie die Datenbankzugriffe auf TSP Service und OBU Client realisiert werden. Plattformbedingt mussten zwei verschiedene Ansätze gewählt werden TSP Datenbank Für den Zugriff auf die Datenbank wird die Java Persistance API (kurz JPA) eingesetzt. JPA ist eine Schnittstelle welche definiert wie Java Laufzeit-Objekte Persistent in einer relationalen Datenbank gespeichert werden können und dies obwohl relationale Datenbanken nicht für objektorientierte Datenstrukturen gedacht sind. Es gibt verschieden Implementationen der JPA Schnittstelle. Für die Implementation des Prototyps wurde das Open-Source Framework EclipseLink eingesetzt. [38][39] Für jede Tabelle der TSP Datenbank gibt es eine Klasse Provider, welche den Zugriff auf die Datenbank Tabelle anbietet. Die Provider-Klassen erweitern die ProviderBase-Klasse, welche die grundlegenden JPA Funktionen persist, merge, remove enthält und die Steuerung der Transaktionen übernimmt. Dadurch ist es möglich, dass während einer Transaktion mehre Provider Klassen und somit Zugriffe auf verschiedene Tabellen möglich sind. (Siehe auch Klassen der Komponente tspservice, Seite 25) OBU Datenbank Die OBU bedient sich einer SQLite Datenbank. Dieses Datenbanksystem wurde explizit für den Einsatz auf Embedded Systemen entwickelt. Es ist ressourcensparend und kann über die Android Database API angesteuert werden. Eine passende ORM Implementation (analog zu JPA) würde es für SQLite ebenfalls geben; diese hat sich aber für den Einsatz in diesem Projekt nicht etabliert. (Die Gründe dafür sind der grosse Overhead bezüglich Speicherplatz, Latenzzeiten und Komplexität). Die SQLite Integration wurde dementsprechend mit Hilfe der Android Bordmittel umgesetzt. Eingesetzt wird eine zentrale Datenbank Helper Klasse sowie für jede Datenbanktabelle eine Providerklasse. Providerklassen implementieren mit Unterstützung der DB Helper Klasse die CRUD Operationen der jeweiligen Datenbanktabelle. (Siehe auch Klassen der Komponente obuclient, Seite 27). Aus Sicherheitsgründen wird die OBUDB im privaten Speicherbereich der OBU Client Applikation abgelegt. Keine andere Anwendung kann auf diesen Bereich zugreifen. 5.6 Kommunikationsschicht Die Anforderungen an die Kommunikationsschichten zwischen den involvierten Komponenten, TSP Service, TSP Client(s) und OBU Client(s) sind vergleichbar mit jenen eines Instant Messaging Systems. Eine Vielzahl von Dienstleistungsnutzern (=OBU) möchte mit einem Dienstleister (=TSP) kommunizieren. Die permanente Verfügbarkeit einer Datenverbindung zwischen TSP und OBU ist nicht garantiert. Es bedarf folglich einer Kommunikationsschicht, welche die gegebene Situation bestmöglich unterstützen kann. Als Lösung wurden mehrere verschiedene Methoden zur Datenübertragung evaluiert: TCP Sockets, WebORB [21] und XMPP [22]. Letzteres Protokoll konnte nach Ansicht der Autoren die Bedürfnisse dieses Projekts am besten befriedigen. Die XMPP-RPC Bibliothek, ein Schulprojekt der Hochschule Rapperswil, schien die Bedürfnisse dieses Projekts geradezu ideal zu befriedigen [20]. TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 48 / 62

49 Report Design-Entscheide Aufbau des Systems Abbildung 22 illustriert den Aufbau und die Kommunikationsflüsse zwischen TSP Service, TSP Client(s) und OBU Client(s). Es wird gezeigt, wie die Peers eigene Schnittstellen bereitstellen und entfernte Schnittstellen nutzen können. Grundsätzlich kann jeder Teilnehmer Schnittstellen über Direktverbindungen anderen Benutzern zugänglich machen. Es ist auch möglich, dass Teilnehmer ihre Schnittstellen in Chat Rooms einer Menge von Benutzern bereitstellen 9. TSP Client(s) XMPP Client (3) Openfire XMPP Server Chat Room «entrance» (2) (3) OBU Client(s) XMPP Client (1) (4) TSP Service XMPP Client Abbildung 22: Physische Konstellation des Kommunikationssystems (1) TSP Service registriert die Schnittstelle ITSP mit Room User in Raum entrance. (2) OBU Clients registrieren ihre Schnittstelle IOBU mit dem XMPP User und verbinden direkt zum TSP User (3) OBU Clients rufen entfernte Methoden von ITSP direkt über den TSP Room User auf, nutzen dabei aber nicht die MultiUserChat Verbindung, sondern eine herkömliche End-zu-End UserChat Verbindung. (4) Die Rückmeldung erhalten OBU Client s über eine Direktverbindung vom TSP User tsp@enterpriselab zum jeweiligen Anfragesteller (OBU Client resp. TSP Client). 9 Das wäre genau die Lösung, welche in diesem Projekt gefragt gewesen wäre. Leider läuft die für Room Chats zuständige MultiUserChat Klasse der Smack Library auf dem Android Betriebssystem nicht fehlerfrei. Der beschriebene Ablauf und die korrespondierenden Pfeile sollen helfen den Workaround zu verstehen. TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 49 / 62

50 Report Design-Entscheide Das XMPP Kommunikationskonzept verlangt also, dass jeder Teilnehmer über eine XMPP Adresse mit dem XMPP Server verbunden ist. Es resultiert eine lose Kopplung zwischen den Kommunikationspartnern, ähnlich wie dies bei Systemen der Fall ist. Die TSP Datenbank muss infolgedessen lediglich die XMPP Adresse jeder OBU kennen. Diese wird einmalig beim Aufsetzen der OBU festgelegt und ändert danach nicht mehr Verbindungsverhalten Laut der Protokollspezifikation von XMPP und der Code-Dokumentation der Smack Library [17] versucht ein XMPP Client die Verbindung permanent aufrecht zu erhalten. Wird eine Verbindung abrupt getrennt, so versucht sich der Client automatisch wieder mit dem XMPP Server zu verbinden. Dieses Verhalten ist insbesondere für die Implementation der OBU Clients sehr interessant, da dort die Verfügbarkeit einer Netzwerkverbindung zu keinem Zeitpunkt garantiert ist. Hinweis für Weiterentwicklung Eine produktive Implementierung dieses Projektsystems würde bedingen, dass in Bezug auf das Verbindungsverhalten tiefgehende Tests durchgeführt würden. Was passiert beispielsweise, wenn ein Client ständig eine qualitativ schlechte GSM Datenverbindung erhält? Wie viel Overhead (und somit Kosten beim Netzwerkprovider) entsteht, wenn sich ein OBU Client ständig neu beim XMPP Server anmeldet? Empfangsbestätigung Vorhergehend wurde erklärt, dass XMPP hilft, die Kommunikationspartner zu entkoppeln. Dabei handelt es sich nicht nur um eine softwaretechnische Entkopplung mit Interfaces, sondern auch um eine zeitliche Entkopplung. Ein Teilnehmer hat die Möglichkeit eine Nachricht an einen anderen Teilnehmer zu senden, auch wenn dieser zum Sendezeitpunkt offline ist. Der Empfänger wird die Nachricht erhalten, sobald er wieder online ist [23]. Hinweis für Weiterentwicklung Die diskutierten Features bezüglich Verbindungsverhalten und Empfangsbestätigung wurden in diesem Projekt nicht implementiert, haben aber bei der Entscheidung der Kommunikationstechnologie eine entscheidende Rolle gespielt. Eine Weiterentwicklung dieses Projekts sollte diesen beiden Punkten gerecht werden Übertragung von komplexen Datenstrukturen Die Übertragung von Objekten über XMPP-RPC (also letztlich über TCP Sockets) bedingt unweigerlich die Serialisierung von Objektinstanzen. Die XMPP-RPC Library [20] wurde für die Übertragung von Basisdatentypen wie String, Integer, Float und Double ausgelegt, lässt aber die Freiheit, den Funktionsumfang mit eigenen Type Factories zu ergänzen. Das vorliegende Projekt verlangt nicht selten, dass komplexe Datenstrukturen wie z.b. typisierte ArrayLists mit mehreren Verschachtelungsebenen zwischen den Kommunikationspartnern ausgetauscht werden müssen. Aus diesem Grund wurde die XMPP-RPC Library mit einer ArrayListFactory ergänzt. Diese Erweiterung machte zudem die Entwicklung eines De/Serializers notwendig. Die Anforderung an diesen De/Serializer war einfach: Eine komplexe, verschachtelte ArrayList soll in einen Byte Stream umgewandelt werden. TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 50 / 62

51 Report Environment-Anforderungen 6 Environment-Anforderungen Die Anforderungen an die Systemumgebung werden stark von der Anwendungsaktivität beeinflusst. Je mehr OBUs von einem TSP verwaltet werden, desto grösser sind die Anforderung an das TSP Server System und die darunterliegende Datenbank. Dasselbe gilt für die OBU Clients: Je grösser die Abrechnungsintervalle, umso mehr Speicherplatz muss lokal auf dem Mobilgerät verfügbar sein. Es gibt grundsätzlich mehrere Events, welche die CPU einer OBU überdurchschnittlich auslasten können. Die grössten CPU Auslastungen seitens OBU werden beim Schreiben von Payment Records erreicht, da während diesem Vorgang der kryptographische Proof sowie das Commitment berechnet wird. Dieser Vorgang wird im Abstand von 1km wiederholt 10. Schnelles Fortbewegen beansprucht die CPU zwar öfter, ist aber im Hinblick auf das Speichern von GPS Wegpunkten effizienter. (Höhere Geschwindigkeit = weniger Wegpunkte und weniger Einträge in der Hilfstabelle zwischen PaymentRecord und Waypoint). OBU Client TSP Client Prozessorleistung Arbeitsspeicher Flash Speicher Betriebssysteme Bildschirmauflösung Prozessorleistung Arbeitsspeicher Festplattenspeicher Betriebssysteme Vorausgesetzte Software 1GHz 256MB RAM 12MB bei 3000km Fahrdistanz 11 Android OS WVGA800 2GHz 2GB RAM 200MB Windows, Linux, Mac OS Java SE Runtime Environment, 1.6.0_21 TSP Application Server Prozessorleistung Arbeitsspeicher Festplattenspeicher Betriebssysteme Netzwerk Vorausgesetzte Software 2GHz 2GB RAM 200MB Windows, Linux, Mac OS TCP Port 5222 (XMPP) Java SE Runtime Environment, 1.6.0_21 XMPP Openfire Server TSP DB Server Prozessorleistung Arbeitsspeicher Festplattenspeicher Betriebssysteme Netzwerk Vorausgesetzte Software 2GHz 2GB RAM 200MB 12 Windows, Linux, Mac OS TCP Port 3306 (MySQL default) Java SE Runtime Environment, 1.6.0_21 MySQL Server Tabelle 9: Anforderungen an die eingesetzte Systemumgebung 10 In eine produktiven PrETP System wäre die Segmentlänge selbstverständlich konfigurierbar. 11 Das Speichern von Payment Records und GPS Waypoints kostet ca. 12MB Speicherplatz. 12 Der benötigte Festplattenspeicher ist abhängig von der Anzahl verwalteter OBU Clients, Karten- und Preisinformationen. TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 51 / 62

52 Report Diskussion 7 Diskussion 7.1 Praktische Umsetzung von PrETP Neben technischen Herausforderungen, welche für den Einsatz eines Road Pricing Systems bewältigt werden müssen, gibt es auch politische Arbeit zu erledigen. Gemäss Art. 82, Abs. 2 der Bundesverfassung ist die Benützung öffentlicher Strassen in der Schweiz gebührenfrei. Diese Bestimmung wurde 1848 eingeführt, da Weg- und Brückengelder als Verkehrsbehinderung angeschaut wurden. Das Parlament hat allerdings die Möglichkeit, Ausnahmen explizit zu bewilligen. So wird beispielsweise für die Benutzung des Strassentunnels am Grossen St. Bernhard eine Gebühr erhoben. Für grössere Abweichungen von dieser Bestimmung ist allerdings eine eigene Verfassungsgrundlage nötig. Deshalb sind die Abgaben für die Nationalstrassen (Autobahnvignette) im Artikel 86 geregelt. Ein neues Road Pricing System mit dynamischen Preisen würde natürlich auch eine neue Verfassungsgrundlage bedingen, um auf Haupt- und Nebenstrassen Gebühren verrechnen zu können. [6] Vorgehensweise bei der Inbetriebnahme einer On-board Unit Für den Einsatz eines elektronischen Mautsystems muss jedes Fahrzeug mit einer OBU ausgestattet werden. Ein Fahrzeug wird vor der Zulassung meist durch einen Garagist fahrtauglich gemacht. Deshalb macht es auch Sinn, dass der Garagist die On-board Unit ins Fahrzeug einbaut. Nachdem die OBU im Fahrzeug angebracht ist, muss diese beim Strassenverkehrsamt registriert werden. Jede OBU besitzt eine eindeutige Identifikationsnummer. Bei der Registration wird diese zusammen mit dem Fahrzeug- Kennzeichen und dem Fahrzeughalter registriert. Bei der ersten Inbetriebnahme erhält die OBU von der TSP die Systemparameter (Schlüssellängen), den Public Key der TSP, sowie die Group Parameters. Danach generiert sich die OBU ihr eigenes Schlüsselpaar und übermittelt ihren Public Key an die TSP. Nachdem das Gerät erfolgreich initialisiert wurde, wird ein Systemtest durchgeführt, um zu prüfen, ob Daten korrekt aufgezeichnet werden und eine Abrechnung gemacht werden kann. Es kann allerdings nicht immer davon ausgegangen werden, dass zwischen einer OBU und einem Fahrzeug-Kennzeichen eine 1-zu-1 Beziehung besteht. Eine mögliche Ausnahme sind Wechselnummern. Eine Wechselnummer kann für verschieden Fahrzeuge verwendet werden, wobei nur jenes Fahrzeug zugelassen ist, an welchem die Nummernschilder angebracht sind. Deshalb ist es möglich, dass einem Nummernschild mehrere OBU s zugewiesen sind. In diesem Fall müsste eine Challenge an alle zugewiesen OBU s gesendet werden. Eine der OBUs müssten in der Lage sein diese Challenge korrekt zu beantworten. TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 52 / 62

53 Report Diskussion 7.2 Vorteile Das primäre Ziel eines neuen Road Pricing Systems in der Schweiz ist es, das Verkehrsproblem in den Städten und Agglomerationen zu entschärfen. Das vorgestellte Konzept ermöglicht den Einsatz eines dynamischen Preismodells. Mit diesem kann für das Befahren einer bestimmten Zone, beispielsweise eines Stadtzentrums, ein höherer Preis verrechnet werden. Dies würde einen Anreiz schaffen, vermehrt die öffentlichen Verkehrsmittel zu verwenden, um in die Stadt zu gelangen. Dadurch würde das Verkehrsaufkommen in den Städten abnehmen, wie die Erfahrung aus dem Ausland zeigt. In Stockholm wurde der Stau um 30-50% reduziert, nachdem eine Gebühr für das Befahren des Stadtzentrums eingeführt wurde. Ein dynamisches Preismodell erlaubt auch zeitliche Abstufungen, sodass auf das stärkere Verkehrsaufkommen im Morgen- und Feierabendverkehr mit höheren Abgaben reagiert werden kann. Fahrzeuglenker würden vermutlich wirtschaftlichere Alternativrouten wählen oder wenn möglich die Stosszeiten komplett vermeiden. Das primäre Ziel eines neuen Road Pricing Systems könnte durch den Einsatz eines dynamischen Preismodells ideal erfüllt werden. Zusätzlich erlaubt das elektronische Road Pricing System die anfallenden Unterhaltskosten für die Strasseninfrastruktur nach dem Verbraucherprinzip auf die Benutzer um zu wälzen. Der zu bezahlende Betrag ist abhängig vom benutzten Strassentyp, Ort und der Befahrungszeit. Dadurch wäre auch das langfristige Ziel, die Finanzierung der Strasseninfrastruktur sicherzustellen, gewährleistet. Dies obwohl die Einnahmen durch die Mineralölsteuern in Zukunft stagnieren werden, weil vermehrt Fahrzeuge mit höherer Energieeffizienz auf den Markt kommen. Zusätzlich würde durch das Verrechnen nach Verbraucherprinzip auch der Transit-Verkehr fairer besteuert werden. Für den Endanwender des Systems, den Fahrzeuglenker, ist es wichtig, dass der Datenschutz gewährleistet ist. Durch das lokale Speichern der GPS Koordinaten auf der On-board Unit wird sichergestellt, dass die Lokationsdaten nicht in fremde Hände gelangen können. Denn es wäre beispielsweise fatal wenn Terroristen den Aufenthaltsort von Regierungsmitgliedern ausfindig machen könnten. Beim Privacy- Preserving Electronic Toll Pricing muss der Fahrzeuglenker nur jene Koordinaten preisgeben, für welche der Toll Charger bereits ein Beweis besitzt, beispielsweise durch eine Parkbusse. Zudem legt die OBU die Koordinaten für eine Challenge nur offen, sofern das Fahrzeug sich tatsächlich zu diesem Zeitpunkt am Ort wo der Beweis erstellt wurde aufgehalten hat. Dadurch ist gewährleistet, dass eine OBU ihre Daten nur preisgeben muss, wenn wirklich eine Challenge vorliegt. Die Autoren dieses Berichts sind der Meinung, dass das in diesem Dokument vorgeschlagene Projektsystem sowohl die Interessen des Strassenverwalters als auch jene des Endbenutzers schützt. TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 53 / 62

54 Report Diskussion 7.3 Schwierigkeiten einer praktischen Umsetzungen Einige Probleme einer praktischen Implementierung eines PrETP-Systems wurden in diesem Projekt einfachheitshalber ausgeblendet und sollten im Falle einer produktiven Umsetzung zwingend berücksichtigt werden. Nachfolgende Abschnitte beschreiben eine (nicht-abschliessende) Auswahl möglicher Probleme Nachweisbarkeit von Manipulationen Durch das Speichern der abgefahrenen Strecken auf der On-board Unit entgeht dem Staat die Möglichkeit Manipulationen aufzudecken oder Probleme zu erkennen. Der Staat erkennt lediglich am Ende einer Abrechnungsperiode, ob die Abrechnung für ein bestimmtes Fahrzeug erfolgreich war oder nicht. Für eine fehlerhafte Abrechnung gibt es zwei mögliche Ursachen: Es kann sein das der Fahrzeuglenker die OBU bewusst manipuliert hat, um eine günstigere Rechnung zu erhalten. Die zweite Ursache könnte eine defekte OBU sein, welche beispielsweise keine Daten aufzeichnet. Im Falle einer Manipulation müsste der Fahrzeuglenker eine Busse erhalten. Bei einer defekten OBU hingegen müsste die OBU ersetzt werden und dem Fahrzeughalter der Preis der befahrenen Strecke in Rechnung gestellt werden. Da es allerdings nicht möglich ist, zu erkennen, ob ein Defekt oder eine Manipulation vorliegt und keine Möglichkeit besteht den korrekten Preis im Nachhinein zu ermitteln, müssen Richtlinien ausgearbeitet werden, wie Fehler bei der Abrechnungsperiode behandelt werden. Der folgende Ansatz wäre für eine fehlerhafte Abrechnung denkbar: Wenn es die erste fehlerhafte Abrechnung für einen Fahrzeuglenker ist, dann wird dem Fahrzeuglenker der durchschnittliche Preis der vorhergehenden Abrechnungsperiode in Rechnung gestellt. Handelt es sich bereits um die zweite fehlerhafte Abrechnung, dann müsste der Fahrzeuglenker zusätzlich zum durchschnittlichen Abrechnungspreis eine Busse bezahlen Umgang mit GPS Funkschatten Eine technische Herausforderung, welche beim Einsatz eines elektronischen Mautsystems gelöst werden muss, ist das Aufzeichnen von Wegpunkten, wenn sich die OBU in einem Funkschatten befindet. Im vorliegenden Prototyp werden Wegpunkte (GPS Koordinaten) nach einem bestimmten Intervall, abhängig von der Fahrgeschwindigkeit, aufgezeichnet. Wenn die Gesamtdistanz der offenen Wegpunkte eine bestimmte Distanz (z.b. 1km) überschreitet, dann wird ein neuer Payment Record angelegt. Fährt ein Fahrzeug beispielsweise nach einer aufgezeichneten Distanz von 800 Meter in einen 1.2 Kilometer langen Tunnel hinein, dann wird der nächste Wegpunkt, wegen dem Funkschatten im Tunnel, erst bei der Ausfahrt erfasst. So beträgt die Gesamtdistanz der offenen Wegpunkte zwei Kilometer. Dadurch würde ein Payment Record für zwei Kilometer angelegt werden, anstelle der üblichen 1km-Abschnitte. Im vorliegend Prototyp gilt die Annahme, dass ein Payment Record einen Kilometer lang ist. Deshalb bezieht sich der Preis eines Payment Records auf einen Kilometer. Das heisst der Fahrzeuglenker müsste für die gefahrenen zwei Kilometer nur den Preis von einem Kilometer bezahlen. TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 54 / 62

55 Report Diskussion Die Unterteilung der aufgezeichneten Wegpunkte in fixe 1km-Abschnitte wäre ein möglicher Ansatz um dieses Problem zu lösen. Wenn die OBU bei der Ausfahrt aus dem Tunnel erkennen würde, dass die Gesamtdistanz der offenen Wegpunkte zwei Kilometer beträgt, dann würden dafür zwei Payment Records angelegt werden. Der Nachteil bei diesem Ansatz ist, dass für beide Payment Records der gleiche Preis verrechnet wird, auch wenn für die Payment Records unterschiedliche Tarife verrechnet werden müssten. Ein anderer Ansatz das Problem mit den falsch verrechneten Strecken zu umgehen, wäre der Einsatz von variablen Streckeneinträgen (Payment Records). Sodass sich Payment Records auf unterschiedliche Distanzen beziehen können, anstelle der fixen Distanz von einem Kilometer pro Payment Record. Damit variable Streckeneinträge möglich sind, muss die OBU neben dem verrechneten Preis auch ein Commitment für die aufgezeichnete Strecke erstellen. Um Missbrauch aufzudecken, muss der Toll Service Provider nicht nur das homomorphe Commitment des Preises prüfen, sondern auch jenes für die Strecke. Zudem müsste der TSP mit Hilfe von TC s Streckenabschnittskontrollen durchführen. Damit bei einer Challenge auch geprüft werden kann, ob die OBU die einzelnen Streckenabschnitte korrekt erfasst hat Tracking von OBUs über XMPP? Auf der Suche nach Möglichkeiten, die Spur eines OBU Clients zu tracken, wurde die Kommunikationsverbindung über XMPP/Openfire genauer analysiert. Da es sich bei der eingesetzten Technologie nicht um eine End-zu-End Verbindung zwischen TSP und OBU handelt, gibt es auch keinen Bedarf, IP Adressen zu speichern. Die IP Verbindung zweier kommunizierenden Chat Partner wird wohl jeweils beim Öffnen einer neuen Chat Session im Memory des Openfire Servers gehalten. Mindestens in der Datenbank sowie in den Log Dateien des Openfire Servers sind keine Hinweise auf ein IP-zu-XMPP Adress- Mapping zu finden. Da Openfire ein quelloffenes Produkt ist, kann ein TSP jederzeit den Code herunterladen und eine selbstgebraute Version von Openfire laufen lassen. So dürfte es keine grosse Hürde sein, die IP Adresse von kommunizierenden Peers auszulesen. Ist die IP Adresse ein Sicherheitsrisiko? Eigentlich nicht. Mit Hilfe der IP Adresse eines GSM Modems kann höchstens festgestellt werden, aus welchem Providernetz die Adresse stammt. In der Regel kann mit Hilfe der IP Adresse gerademal auf ein Land oder eine bestimmte Region geschlossen werden aber nicht mal diese Information muss zwingend korrekt sein. Das Risiko für ein erfolgreiches Tracking von OBUs über die XMPP/IP Adresse scheint ziemlich unrealistisch zu sein. Ein weiteres Mittel zum Schutz der OBU wäre ein VPN, welches jeweils nach dem Starten des Android Betriebssystems und vor dem Starten der OBU Client Applikation aufgebaut wird. Der Anbieter des VPN s dürfte dann natürlich keine Beziehung zum TSP pflegen, da ansonsten wieder ein Mapping zwischen externer und interner IP Adresse ausgemacht werden könnte. TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 55 / 62

56 Report Diskussion Positionierung der Toll Charger Analog zum Reglement für das Positionieren von Geschwindigkeitsmessanlagen, welches die Polizei anwendet, bestehen auch Regeln und Einschränkungen für das Positionieren von Toll Charger. Nicht jede Lokation ist geeignet, um Challenges von Fahrzeugen zu erfassen. Die Segmentlänge von Payment Records spielt eine wesentliche Rolle: Bei der Anwendung des vorgeschlagenen Preisberechnungsmodells 13 kann es vorkommen, dass der Grossteil eines Abrechnungssegments in Zone A gefahren wird, das Segment jedoch erst in Zone B die 1km-Marke überschreitet und daher der ganze Kilometer erst in Zone B abgerechnet wird. Diese Abrechnungsstrategie verhindert das Positionieren von Toll Charger entlang von Kartengrenzen mit unterschiedlichen Zonentarifen und zwar in einem Abstand von der Länge eines Abrechnungssegments (z.b. 1km). Ansonsten läuft der TSP in die Gefahr, dass die OBU auf Challenges falsche Responses zurücksendet, obwohl diese zum gegebenen Zeitpunkt den bestimmten Toll Charger korrekt passiert hat. Abbildung 23 illustriert das beschriebene Problem und gibt zwei geeignete Positionierungsmöglichkeiten für TCs (TC1 für die rote Tarifzone und TC3 für die blaue Tarifzone) sowie eine Positionierungsmöglichkeit, welche zu Problemen führen kann (TC2 im Graubereich). Abbildung 23: Das Positionieren von Toll Charger bedingt das Einhalten bestimmter Regeln Dieses Positionierungsproblem könnte entschärft werden, indem die Segmentlänge verkürzt würde (z.b. 100m Segmente). Dann müsste jedoch viel mehr Rechenleistung aufgewendet werden, um die höhere Anzahl Payment Records zu bewältigen. 13 Siehe Kapitel 5.2, Seite 45 TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 56 / 62

57 Report Diskussion Zeitsynchronisation Die involvierten Komponenten, insbesondere die TCs und die OBU Clients, müssen sich an eine strikte Zeitsynchronisation halten. Sind die Abweichungen zwischen Zeitstempeln von TCs verglichen mit Zeitstempeln von OBUs zu gross, so könnte die betroffene OBU einen Proof nicht korrekt bestätigen. Es bestünde der Verdacht, dass die OBU ihre Weg-/Zeitinformationen manipuliert hat. Wichtig für eine erfolgreiche Zeitsynchronisation scheint zu sein, dass: alle Komponenten denselben Zeitgeber zur Synchronisation nutzen die Synchronisation mehrmals täglich durchgeführt wird, um die Abweichung gering zu halten Für Android-basierte Geräte scheint es bereits reife Produkte zu geben, die Zeitsynchronisation und Zeitzonenunterstützung bieten [43]. Systeme, die sich zu 100% auf eine synchrone Zeiteinstellung verlassen müssen, sind in der Praxis jedoch störungsanfällig Zeitzonen und Daylight Saving Time Es ist davon auszugehen, dass ein PrETP System über mehrere Zeitzonen operieren muss. Bei nicht korrekter Implementierung von Zeitstempeln kann ein System rasch viele Fehler verursachen. Es ist beispielsweise zu beachten, dass Zeitstempel immer als UTC Werte gespeichert werden. Die OBUs müssen laufend die aktuelle Zeitzone sowie den Daylight Saving Time Offset mitberücksichtigen [44]. In Europa sind dies hauptsächlich vier Zeitzonen mit je einer Stunde Offset relativ zur Greenwich Mean Time (GMT). Abbildung 24: Zeitzonen in Europa [45] TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 57 / 62

58 Report Diskussion 7.4 Mögliche Weiterentwicklungen Die nachfolgenden Abschnitte geben Impulse zur Weitergestaltung des vorliegenden PrETP Systems ORM für SQLite auf Android Die OBU Client Applikation ist so implementiert, dass CRUD Kommandos direkt auf die Datenbank angewendet werden. Dieses Vorgehen erhöht die Kopplung zwischen Logik und Daten massiv. Eine Weiterentwicklung sollte daher unbedingt ein Refactoring im Bereich des Datenbankzugriffs ins Auge fassen. Es gibt Objekt-relationales Mapper (ORM) für SQLite und Android, welcher die Bedürfnisse dieses Projekts decken könnten [41]. Vor dem Refactoring muss mit einem Prototyp geprüft werden, ob die vom OBU Client bereitgestellten Ressourcen ausreichen, um die Datenbankoperationen über einen OR-Mapper laufen zu lassen Generischer DTO-Assembler Das Umwandeln von Entity Objekten in Data Transfer Objekte wird auf TSP und OBU jeweils für jeden Datentyp manuell vorgenommen. Die Provider-Klassen stellen Methoden bereit, um zwischen Entity Objekt und DTO zu konvertieren. Diese Aufgabe könnte ein generischer DTO-Assembler übernehmen [42] Tarifzonen anhand des Strassentyps erkennen Im vorliegenden Prototyp, sowie im Konzept der KU Leuven, werden die Karten in Tarifzonen unterteilt. Jede Zone wird durch GPS Koordinaten abgesteckt und abhängig von der Tageszeit mit einem Kilometertarif belegt. Wenn man für verschiedene Strassentypen unterschiedliche Preise verrechnen will, so müssten die Zonen entlang der Strassengrenze geführt werden. Abbildung 25 zeigt ein Beispiel, in welchem zwischen Autobahn bzw. Kantonsstrasse unterschieden wird. Die Anzahl der zu erfassenden Kartenabgrenzungen wäre immens. Hingegen kann ein Stadtzentrum mit einer einzigen Abbildung 25: Abstecken der Zonen entlang der Strasse grossen Zone abgesteckt werden, wodurch weniger Datensätze in der Map resp. GPSPoint Tabelle anfallen. Damit für das Abstecken von Strassen nicht unzählige Zonen gespeichert werden müssen, wäre es sinnvoll eine API bzw. Service zu benutzen, welcher anhand von GPS Koordinaten zurück meldet, auf welcher Strasse man sich befindet. Dabei muss sichergestellt werden, dass der Service diese Bestimmung anhand der lokal verfügbaren Daten vornehmen kann. Ansonsten besteht die Gefahr, dass der Fahrzeuglenker seine Position preisgeben muss. TA.PAWI.FS2012 Aspects of Privacy-Preserving Toll Pricing C. Moser / T. Galliker 58 / 62