Offene Plattform für fortschrittliche Verkehrsprognosen aus heterogenen Daten

Bei der technischen Implementierung mussten viele wissenschaftliche und technische Hürden genommen werden. Hier beschreiben wir, wie wir diese angegangen sind.

Technische Umsetzung

Wie lassen sich die zahlreichen Ziele, die auf den ersten Blick widersprüchlich erscheinen mögen, tatsächlich realisieren?

Die erste Prämisse bei der Umsetzung war, über eine zentrale Plattform nachzudenken: Denn der Erfolg der datenbasierten Dienste geht eng einher mit dem Cloud-Gedanken. Statt dezentraler, eigenständiger Programme, die von jedem Benutzer installiert, gewartet und gepflegt werden wollen und damit einigen Aufwand erzeugen, wird einfach ein zentraler Dienst angeboten. Der ist sofort nutzbar und die notwendige Wartung kann komplett vom Anbieter übernommen werden. Wer überlegt, wie selten er den Ausfall eines der wesentlichen Dienste im Internet erlebt hat, und vergleicht, wie häufig der eigene Computer streikt, erkennt schnell die unschlagbaren Vorteile von zentralen Plattformen.

Aber wie können wir die durch die zentrale Plattform gewonnene Effizienz mit gelebtem Schutz der Daten kombinieren? Zwar sind Betreiber solcher Plattform per Gesetz zu Datenschutz verpflichtet, aber tatsächlich ist eine echte Kontrolle der Einhaltung kaum realistisch. Selbst ohne echte Kontrollen wurden schon diverse Skandale bekannt, was darauf hindeutet, dass wir den Schutz der Daten nicht unbedingt nur auf Vertrauen basieren lassen sollten.

Wie können aber Daten zentral gespeichert werden, ohne dass der Betreiber der Plattform die Daten lesen kann? Zu Hilfe kommt uns hier die moderne Kryptografie, die sich mit Verschlüsselungsmethoden auseinandersetzt. Diese Methoden sind vielfach erprobt und sichern heute schon einen großen Teil der Kommunikation über das Internet vor Lauschern und Manipulationen.

Um zu verstehen, wie OPA_TAD die Daten schützt, geben wir eine kurze Einführung in die grundlegenden Werkzeuge, die uns zur Verfügung stehen: Hashfunktionen sowie symmetrische und asymmetrische Verschlüsselungen. Wer damit bereits vertraut ist, kann weiter unten direkt mehr über unsere Anwendung der Methoden erfahren.

Bei OPA_TAD verwenden wir Hashfunktionen in Vorgängen, bei denen eine eindeutige Identifikation und Zuordnung der Daten zu einem bestimmten Nutzer möglich sind, so wie es zum Beispiel beim Hochladen der Daten auf die zentrale Plattform der Fall sein könnte. Das hat zum Ziel, dass die Identität des Nutzers gegenüber der Plattform verschleiert bleibt. In diesem Abschnitt erläutern wir, wie Hashfunktionen im Allgemeinen funktionieren und veranschaulichen dies am Beispiel von Passwörtern.

Hashfunktionen berechnen aus einem Wert, wie zum Beispiel der Zeichenfolge eines Passworts, einen anderen Wert einer bestimmten Länge, den sogenannten Hashwert. Immer wenn die gleiche Zeichenfolge eingegeben wird, ergibt sich der gleiche Hashwert. Ändert man aber nur ein Zeichen im Passwort, kommt ein völlig anderes Ergebnis des Hashwertes heraus. Wichtig ist, dass sich die Funktion nicht umdrehen lässt, es also unmöglich ist, aus dem Ergebnis die Eingabe zu berechnen. Daher werden sie häufig verwendet, um Passwörter zu speichern: Statt des Passworts im Klartext wird nur der Hashwert gespeichert. Wenn sich ein Benutzer einloggen möchte und das Passwort eingibt, wird wieder die Hashfunktion auf die Eingabe angewendet. War das Passwort korrekt, stimmt das Ergebnis mit dem gespeicherten überein. Die direkte Auswirkung sieht man, wenn man sein Passwort vergessen hat: Statt das Passwort per Mail zugesendet zu bekommen, muss man ein neues vergeben. Warum? Weil der Dienst selbst das Passwort nicht mehr kennt, sondern nur noch das Ergebnis der Hashfunktion!

Damit hat es auch ein Angreifer, der Zugriff auf die Passwortdatenbank erlangt, schwer. Er kennt die Passwörter der Benutzer nicht und kann sich daher nicht als ein Benutzer einloggen! Um die Passwörter zu erfahren, bleibt ihm nichts anderes übrig, als zu raten: Er kann alle möglichen Passwortkombinationen in die Hashfunktion eingeben und prüfen, ob das Ergebnis zufällig in der Tabelle vorkommt. Verwenden alle Benutzer lange Passwörter, dauert eine solche Suche aber sehr, sehr, sehr lange, weil bereits für acht alphanumerische Stellen 320 Quintillionen Kombinationen durchprobiert werden müssten.

Hashfunktionen sind damit zwar für viele Anwendungsbereiche nützlich, aber sie können nicht unsere Daten selbst schützen. Zwar könnte man nur die Hashwerte speichern, aber dann könnten wir die Ursprungsdaten nicht mehr rekonstruieren. Daher brauchen wir dafür andere Verfahren.


Bei OPA_TAD benötigen wir einen Mechanismus, mit dem es zwei Nutzern ermöglicht wird, auf einen Datensatz zuzugreifen, ohne dass die Plattform oder weitere Nutzer dazu in der Lage sind. Wir verwenden hierfür ein Konzept, dass sich am leichtesten mit einem normalen (z. B. Fahrrad- oder Auto-) Schlüssel vergleichen lässt. Wenn ich möchte, dass jemand anderes Zutritt zu meiner Wohnung hat oder regelmäßig mein Auto nutzen kann, gebe ich dieser Person eine exakte Kopie meines eigenen Schlüssels. Analog dazu geschiet es auch bei der symmetrischen Verschlüsselung von Daten: Ein Datenlieferant, der einem anderen Nutzer seine Daten zur Verfügung stellen möchte, händigt dem Nutzer, der mit den Daten eine Analyse ausführen möchte, eine exakte Kopie des Schlüssels aus. Das nennt man auch „symmetrisches Schlüsselpaar“. Im folgenden Abschnitt erläutern wir, wozu dieses Verfahren im Allgemeinen gut ist und warum wir für das OPA_TAD-Gesamtkonzept noch darüber hinaus gehen müssen.

Methoden der symmetrischen Verschlüsselung werden angewendet, wenn Informationen zwischen Akteuren ausgetauscht werden sollen, ohne dass ein Angreifer mitlesen kann. Dazu müssen sich alle Akteure auf einen geheimen Schlüssel einigen, mit dem die Daten dann verschlüsselt werden. Bekommt ein Angreifer Zugriff auf die verschlüsselten Daten, kann er die Daten ohne diesen Schlüssel nicht lesen. Im Grunde bleibt nur, zufällige Schlüssel durchzuprobieren und zu prüfen, ob das Ergebnis korrekt sein kann, was wieder zu lange dauert. Besitzt man aber den Schlüssel, ist die Entschlüsselung einfach durchzuführen und die ursprünglichen Daten sind wieder vollständig rekonstruiert.

Wir können mit symmetrischer Verschlüsselung die Kommunikation zwischen zwei Personen gegen Mitlesen und Manipulation der Daten schützen. Voraussetzung ist aber, dass beide den gleichen Schlüssel vorliegen haben. Ein Problem besteht hierbei darin, dass beide Parteien diesen gleichen Schlüssel auf irgendeine Weise austauschen müssen. Damit Kommunikation auch ohne geheime Treffen im Mondschein und Austausch von langen Codebüchern möglich ist, bedarf es noch einen dritten Baustein: der sicheren Übertragung der Daten.

Bei der asymmetrischen Verschlüsselung werden zwei Schlüssel benötigt: Mit einem werden Daten verschlüsselt und mit dem anderen können die Daten wieder entschlüsselt werden, daher die Bezeichnung als asymmetrisch. Eine passende Analogie ist die eines Schnappschlosses, wie man sie häufig an Haustüren findet: mit einem derartigen Schlosss lässt sich eine Tür schließen, ohne dass man den passenden Schlüssel hat – sobald die Tür ins Schloss fällt, greift der Schnapper in die Falle und blockiert die Tür. Öffnen kann man die Tür dann nur noch, wenn man im Besitz des passenden Schlüssels ist. In die digitale Welt übertragen, wird das Schloss zum sogenannten „öffentlichen Schlüssel“ (jeder kann damit die Tür abschließen), der Schlüssel zum Schloss (den ich brauche, um die Tür wieder zu öffnen) wird als „privater Schlüssel“ bezeichnet. Dadurch können geheime Treffen bei Mondschein entfallen, denn der erste Schlüssel – unser Schnappschloss –  kann einfach veröffentlicht werden! Um jemandem eine Nachricht zukommen zu lassen, kann sie mit seinem öffentlichen Schlüssel verschlüsselt werden: die Tür fällt ins Schloss und kann nur noch von Personen mit dem passenden Schlüssel geöffnet werden – in diesem Fall ist das der Empfänger der Nachricht. Nur er kann sie entschlüsseln und lesen, denn dazu benötigt man den geheim gehaltenen zweiten Schlüssel.

Wer sich also mal gefragt hat, warum man ohne Codebuch sicher im Internet surfen kann: Asymmetrische Verschlüsselung ist einer der Grundpfeiler!

Allerdings sind Verfahren für asymmetrische Verschlüsselung ungleich rechenaufwändiger als genauso sichere, symmetrische Verfahren. Es wäre für unsere heutigen Endgeräte schlicht zu aufwändig, die kompletten Daten für eine Übertragung asymmetrisch zu verschlüsseln. Deshalb benutzt man einfach eine Kombination aus symmetrischen und asymmetrischen Verfahren: Dazu muss nur einer der Akteure einen neuen symmetrischen Schlüssel generieren, also zufällig auswürfeln, und ihn dann mit dem bekannten, öffentlichen Schlüssel des Gegenübers asymmetrisch verschlüsseln und versenden. Nun kann nur noch das Gegenüber mit seinem passenden, geheimen Schlüssel den generierten, symmetrischen Schlüssel rekonstruieren. Beide Akteure verfügen nun über den gleichen Schlüssel zur symmetrischen Verschlüsselung, den sonst niemand kennen kann und können nun auf die effizientere symmetrische Verschlüsselung umschalten.

Sichere Speicherung von Daten

Die Idee ist, eine Plattform zu erarbeiten, bei der selbst der Betreiber nicht in der Lage ist, vorliegende Daten zu entschlüsseln oder Rückschlüsse auf einzelne Personen ziehen zu können. Dazu werden sowohl Hashfunktionen als auch symmetrische und asymmetrische Verschlüsselung eingesetzt, die wir weiter oben erläutert haben.

Jeder Benutzer verfügt über ein asymmetrisches Schlüsselpaar, bestehend aus einem öffentlichen (Schlüssel A) und einem geheimen Schlüssel (Schlüssel B). Den öffentlichen Schlüssel macht er bei der Anmeldung auf der Plattform bekannt. Der geheime Schlüssel ist nur ihm bekannt.

Um eine Datenlieferung eines Benutzers wiederzuerkennen, also identifizieren zu können, wird ein Identifikationsmechanismus benötigt. Dies realisieren wir, indem der Nutzer eine sehr große Zeichenfolge generiert. Damit wird es extrem unwahrscheinlich, dass zwei Benutzer genau die gleiche zufällige Zeichenfolge erstellen. Diese Zeichenfolge nennen wir ab nun Identifikator der Daten, kurz ID.

Der Benutzer verschlüsselt die Daten, die er an die Plattform senden möchte, mit einem symmetrischen Schlüssel (Schlüssel C). Dieser Schlüssel wird mit dem öffentlichen der beiden asymmetrischen Schlüssel (A) verschlüsselt. Das alles passiert, ohne dass der Benutzer es mitbekommt, „hinter den Kulissen“ der Plattform.

Der symmetrische Schlüssel wird hier also dazu verwendet, die Daten des Datenlieferanten dem Analysten zur Verfügung zu stellen. Damit dieser sicher transportiert werden kann, wird er in ein Schloss eingepackt, dessen Schlüssel nur der Datenanalyst hat. Der Schlüssel selbst ist also verschlüsselt.

An die Plattform liefert der Datenlieferant nun die eindeutige ID zusammen mit dem asymmetrisch verschlüsselten Schlüssel und den Daten. Die Plattform trennt nun die Daten von den Metadaten: Die Daten werden in einer Big-Data-Datenbank gespeichert, und zwar unter dem Hashwert der ID. Durch den Hashwert ist die ID weiterhin eindeutig, aber für die Plattform ist nicht mehr rekonstruierbar, von wem die Daten stammten.

In den Metadaten wird diese Datenlieferung für den Benutzer registriert, zusammen mit dem für die Entschlüsselung notwendigen Schlüssel. Diese Registrierung darf aber nicht die ID selbst enthalten, da dann eine Verbindung zwischen den Daten und dem Benutzer hergestellt werden könnte. Stattdessen wird die ID mit dem öffentlichen Schlüssel (Schlüssel A) verschlüsselt gespeichert.

Damit kann nur der Benutzer alle seine Einträge abrufen und mittels des geheimen, asymmetrischen Schlüssels (Schlüssel C) die IDs rekonstruieren und so wieder auf die Daten zugreifen, und niemand sonst! Zwar kennt die Plattform zum Zeitpunkt des Uploads die Verbindung zwischen dem Benutzer und den Daten, muss diese aber nicht dauerhaft speichern. Selbst mit vollem Zugriff auf die gespeicherten Daten und Metadaten könnte ein Angreifer oder der Betreiber selbst nicht nachträglich einen Bezug zwischen den Daten und einzelnen Benutzern herstellen.

Noch offene Herausforderungen

Allerdings würde ein bösartiger Plattformbetreiber zum Zeitpunkt der Speicherung einer Datenlieferung über alle notwendigen Informationen verfügen, um diesen Bezug herzustellen. Dem ließe sich nur entgegentreten, indem Registrierung der Metadaten und Upload der verschlüsselten Daten zeitlich entzerrt vom Clientsystem vorgenommen werden. Dann könnte die Plattform aber nicht mehr überprüfen, ob für die hochgeladenen Daten auch ein Metadateneintrag existiert. Die Plattform kann dem Benutzer dann nicht mehr garantieren, dass er alle seine Daten löschen kann, was nach heutigem Recht gegen die DSGVO verstößt. Deshalb kommt diese Form der Verschärfung bei OPA_TAD zurzeit nicht zum Einsatz. Des Weiteren könnten diese Daten dann nicht mit anderen Nutzern zu Analysezwecken geteilt werden. Entsprechend müssen wir von einem Plattformbetreiber ausgehen, der zum Zeitpunkt des Speicherns von Daten vertrauenswürdig ist. Schwindet das Vertrauen später, wechselt zum Beispiel der Betreiber oder bei einem öffentlichen Betreiber die Regierung, können die Benutzer das Speichern und Nutzen von Daten einstellen. Die bereits vorhandenen Daten sind dennoch sicher vor Zugriff geschützt, was bei heutigen Lösungen nicht der Fall ist, denn bei denen müssen wir von einem dauerhaft vertrauenswürdigen Betreiber ausgehen, da er immer in der Lage ist, unsere Daten zu lesen. Diese schwächere Form des notwendigen Vertrauens in den Betreiber einer Plattform wird im Folgenden „temporär vertrauenswürdig“ genannt.

Warum ist es so wichtig, dass Datenlieferungen nicht einzelnen Benutzern zuzuordnen sind, obwohl die Daten doch verschlüsselt vorliegen?

Das liegt daran, dass zum einen die Existenz von Daten bereits etwas über den Benutzer aussagen kann. Gehen wir zum Beispiel von einem Dienst aus, bei dem wir die Bewegungstrajektorien beim Joggen abspeichern, also die Aufzeichnung wann wir wo waren – unsere Laufstrecke. Bleiben die Daten aus, kann man davon ausgehen, dass die Person zu diesem Zeitpunkt nicht joggen war. Das ist zwar nicht viel Information, kann aber im falschen Zeitpunkt das Leben einer Person bedrohen, wenn sie vielleicht gute Gründe hatte, über die wahre, vielleicht politische, Aktivität zu schweigen. Ändert sich das politische Klima, können so Daten aus der Vergangenheit extrem gefährlich werden, weshalb wir beim Plattformdesign nur von einem temporär vertrauenswürdigen Betreiber ausgehen sollten.

Stärker als die reine Existenz von Daten wiegt die Notwendigkeit, Daten in der Masse auch zu finden. Da Daten keinerlei Nutzen haben, wenn wir sie nur aufzeichnen, müssen wir sie analysieren können. Damit wir Daten aber analysieren können, müssen wir relevante Daten erst in der Masse der Daten finden. Da wir bei OPA_TAD Daten aus dem Mobilitätssektor betrachten, sind der konkrete Ort und die Zeit, die die Daten beschreiben von essenzieller Bedeutung. Für aktuelle Fragen zum Stauverhalten auf der A 40 durch Nordrhein-Westfalen braucht man weder Daten aus den 70er-Jahren noch Daten aus Niedersachsen. Entsprechend möchte man die Analyse auf relevante Daten einschränken können. Für OPA_TAD haben wir daher den Ort, bestimmt durch Längen- und Breitengrad, sowie die Uhrzeit als Zugriffsindex gewählt, sodass relevante Daten effizient bestimmt werden können.

Damit ein Zugriffsindex aber funktioniert, kann er nicht vollständig verschlüsselt werden. Mindestens die Reihenfolge der Datenpunkte unter einer Sortierung muss stabil bleiben. Diese Angaben sagen entsprechend viel über den Besitzer aus, bei Trajektorien enthalten sie sogar bereits alle Daten! Daher darf der Bezug zum Besitzer nicht leicht herstellbar sein.

Natürlich könnte man versuchen, über die Trajektorien selbst einen Bezug zu Personen herzustellen, z. B. wären sich häufig wiederholende Ausgangsorte ein guter Identifikator: dies ist mit hoher Wahrscheinlichkeit das Zuhause oder der Arbeitsort der Person. Um das zu erschweren, setzt OPA_TAD auf zwei Maßnahmen: Erstens werden alle Indexpunkte zufällig über den Globus verschoben und skaliert, sodass es wieder den persönlichen, geheimen Schlüssel des Datenbesitzers braucht, um die Verschiebung rückgängig zu machen. Zum anderen können Trajektorien auf den Clientgeräten bereits anonymisiert werden, indem zum Beispiel innerhalb eines Radius um die eigene Wohnung keine Punkte gemessen werden.

Sichere Analyse von Daten

Daten nur zu speichern, bringt wenig Mehrwert. Entsprechend möchten wir sie auch analysieren können. Natürlich kann jeder, der Daten verschlüsselt auf der Plattform speichert, diese wieder herunterladen, entschlüsseln und auf seinem Endgerät analysieren. Das unterstützen wir sogar mit einer speziellen Erweiterung für eine weitverbreitete Open-Source-Analyseplattform, dazu unten mehr.

Der wirkliche Mehrwert entsteht aber erst durch die nutzerübergreifende Analyse: Wenn wir den Nahverkehr optimieren wollen, brauchen wir die Bewegungsdaten von möglichst vielen Menschen, denn unsere Routen sollen möglichst vielen Menschen eine einfache Bewegung ohne eigenen PKW ermöglichen.

Am einfachsten ist das umzusetzen, indem der Analyst eine Kopie der Daten erhält, immerhin können Daten ja beliebig kopiert werden. Aber wollen wir das? Genau aufgrund dieser Tatsache, nämlich dass Daten beliebig kopiert werden können, verlieren wir dann die Kontrolle über die Daten. Der Analyst könnte sie noch für viele weitere Zwecke nutzen, mit denen wir nicht einverstanden wären oder sie auch Dritten zur Verfügung stellen. Sollen Daten von der Qualität her noch benutzbar sein, ist es sehr schwer oder vielleicht auch unmöglich, sie vollständig zu anonymisieren. Es könnte also jemand versucht sein, aus den vermeintlich anonymisierten Daten wieder einen Personenbezug herzustellen.

Um das zu vermeiden, folgen wir bei OPA_TAD einem alternativen Weg: Statt Datenkopien zur Analyse zu senden, lassen wir die Analyse zu den Daten kommen. Um Daten auf OPA_TAD zu analysieren, konstruiert man dazu zunächst aus vorgefertigten Bausteinen eine Analyse. Die Bausteine können flexibel miteinander kombiniert und durch den entstehenden Datenfluss kann fast jeder Analysebedarf erfüllt werden. Diese Definition der Analyse schickt man zur Plattform, die sie dann ausführt. Die bei der Analyse genutzten Daten brauchen so die Plattform nie zu verlassen und es reicht, die Ergebnisse verfügbar zu machen. Natürlich muss dann für die Ergebnisse garantiert werden, dass sie nicht schlicht eine Kopie der Daten sind – dass also kein böswillig Handelnder auf diese Weise versucht, das Schutzkonzept zu umgehen, um danach die Daten zu seiner Verfügung zu haben. Gleichzeitig benötigt es einen Mechanismus, mit dem Benutzer ihre Daten anderen für Analysen zur Verfügung stellen können.

Die Vorteile des Baukastensystems

Heutzutage sind einige Programmiersprachen für Datenanalysen sehr populär. Mit diesen Programmiersprachen haben die Analysten die Möglichkeit, ihre Analysen frei nach ihren Wünschen und Bedürfnissen zu gestalten. Warum entscheiden wir uns trotzdem für ein vergleichsweise limitiertes Baukastensystem? Während es bei beliebigem Programmcode unmöglich ist, automatisch zu entscheiden, was er tut und ob er vielleicht heimlich versucht, Datenkopien in das Ergebnis zu schmuggeln, kann die Implementierung der Bausteine komplett kontrolliert werden. Denn statt des Programmcodes wird nur eine Definition der Form „jetzt Daten mit Baustein X unter folgenden Einstellungen verarbeiten“ übertragen, sodass die eigentliche Implementierung auf der Plattform erfolgt.

Unser Ziel ist es, einen möglichst umfangreichen Satz an Bausteinen zur Verfügung zu stellen, über den dennoch Garantien zugesichert werden können, dass Ergebnisse ein bestimmtes Niveau der Anonymisierung erreichen, wenn Daten von Benutzern verwendet werden. Gleichzeitig sind wir der Ansicht, dass ein Baukastensystem schneller und mit weniger Vorwissen genutzt werden kann, was den Zugang zu Daten niedrigschwelliger gestaltet und entsprechend zu Demokratisierung und Teilhabe beiträgt.

Wenn ein solcher Baukasten verfügbar ist, können Daten analysiert werden, ohne dass die Ergebnisse etwas über einzelne Nutzer verraten. Aber die Daten liegen zunächst verschlüsselt auf der Plattform vor. Wie können die verschlüsselten Daten analysiert werden?

Zunächst gar nicht. Sind Daten sicher verschlüsselt, können sie eben nicht genutzt werden. Daher greift hier wieder, dass wir der Plattform temporär vertrauen müssen: Für die Analyse müssen wir ihr einmal die symmetrischen Schlüssel zur Verfügung stellen, mit denen sie die Daten temporär entschlüsseln kann. Ist sie zu dem Zeitpunkt vertrauenswürdig, kann sie die Daten zusammen mit den Schlüsseln anschließend sofort wieder löschen, bzw. speichert diese gar nicht erst ab. Nach der Analyse sind die Daten dann wieder sicher verwahrt und somit auch vor späteren erfolgreichen Angriffen geschützt.

Im Rahmen des ebenfalls durch das BMVI geförderten Projektes SPAA arbeiten wir zurzeit an einem Konzept, wie Daten so verschlüsselt werden können, dass sie für eine ganz bestimmte Analyse eben doch nutzbar sind. Hierbei handelt es sich aber noch um Grundlagenforschung.

Sicheres Teilen von Daten

Wie bekommt jemand aber nun für eine Analyse Zugriff auf die Daten anderer Benutzer? Setzen wir das obige Beispiel der örtlichen Verkehrsbetriebe fort: Deren Data Scientist möchte die Daten von Nutzern aus der entsprechenden Stadt verwenden. Dafür muss der Analyst der Verkehrsbetriebe eine Anfrage an die Nutzer senden, ob sie ihm ihre Daten für den genannten Zweck der Verbesserung des öffentlichen Nahverkehrs zur Verfügung stellen möchten. Hier trägt OPA_TAD zur Teilhabe bei, da Nutzer jetzt frei entscheiden können und damit aktiv etwas beitragen können. Gleichzeitig sind sie immer darüber im Bilde, wofür ihre Daten verwendet werden.

Wenn die Nutzer ihre Daten sicher gespeichert haben, haben aber nur sie den geheimen, asymmetrischen Schlüssel, mit dem sie die Daten lesen können. Zur Erinnerung: Um das zu tun, müssen sie mit dem asymmetrischen Schlüssel zunächst die ID und den für jede Datenlieferung generierten symmetrischen Schlüssel entschlüsseln und können mit diesem dann die über die ID gefundenen Daten selbst entschlüsseln. Eine ausführliche Erklärung findet sich weiter oben.

Daraus folgt aber, wenn man seine Daten mit einem anderen Benutzer teilen möchte, braucht man sie gar nicht zu kopieren: Es reicht völlig, wenn man ihm die ID der Daten zusammen mit dem entsprechenden symmetrischen Schlüssel mitteilt. Das Beste daran ist: Das ist völlig anonym möglich. Man muss also den Verkehrsbetrieben gar nicht sagen, wer man ist, noch könnte ein erfolgreicher Angreifer später nachvollziehen, von wem die Daten geteilt wurden. Die Plattform wird zwischendurch lediglich informiert, um den Besitz der geteilten Daten zu prüfen, notwendige Informationen zu hinterlegen, um das Teilen rückgängig zu machen und Verwendungseinschränkungen für die geteilten Daten zu vermerken. Dazu reicht aber wieder die Annahme der temporär vertrauenswürdigen Plattform.

Die Ergebnisse

Um einen Eindruck von den Ergebnissen des OPA_TAD Projekts zu bekommen, schauen Sie sich gerne unsere beiden Demonstratoren an!

OPA_TAD Verkehrsprognose

zur Anwendung

Data Gathering App

zur Anwendung