Demonstratoren

Hier wird der aktuelle Entwicklungsstand der P-Lib dargestellt und es erfolgt eine Beschreibung einzelner Bestandteile der graphischen P-Lib Benutzerschnittstelle. Es sei darauf aufmerksam gemacht, dass eine P-Lib-App stets eine Referenz auf die graphische P-Lib Benutzerschnittstelle in Form eines Menüpunktes bieten muss. Ohne eine solche Referenz hat der Benutzer nicht die Möglichkeit Datenschutzeinstellungen vorzunehmen bzw. getroffene Entscheidungen zu revidieren. Die Realisierung erfolgt durch Aufruf einer entsprechenden Methode der P-Lib-API. Die Feststellung der Existenz einer solchen Referenz erfolgt während der Auditierung.

P-Lib Hauptmenü

Abbildung 1 stellt die Einstiegsseite der graphischen P-Lib Benutzerschnittstelle (im Nachfolgenden einfach P-Lib-UI genannt) dar. In der oberen Titelzeile wird der Name der P-Lib-App dargestellt und kann von daher variieren. Es sei an dieser Stelle darauf aufmerksam gemacht, dass die zugrunde liegende Implementierung dieser P-Lib-UI außerhalb des Einflussbereiches des App-Entwicklers liegt. Gegenwärtig unterscheidet die P-Lib-UI sieben Kategorien, auf die nachfolgend eingegangen wird.

Abbildung 1: P-Lib Hauptmenü

Masterschlüssel

Unter Abbildung 2 sind verschiedene Funktionalitäten im Hinblick der Exportierung und der Importierung des Masterschlüssels dargestellt. Der beispielhafte Export in dieser Abbildung wird mittels QR-Code umgesetzt. Es ist auch möglich den Masterschlüssel in Form einer Datei zu exportieren und diesem auf dem lokalen Speicher zu speichern. Da der Masterschlüssel als Schutzgegenstand zu erachten ist, da aus diesem deterministisch Schlüssel erzeugt werden, muss der Masterschlüssel beim Exportieren in Abhängigkeit eines Benutzerkennwortes verschlüsselt werden.

Mittels des Menüpunkts „Generate new Master Key“ kann der aktuelle Masterschlüssel mit einem zufällig neu generierten ersetzt werden. Dabei gilt, genauso auch beim Importieren eines bestehenden Masterschlüssels, dass sämtliche Daten, die mit dem durch den zu überschreibenden Masterschlüssel generierten Schlüsseln erzeugt bzw. modifiziert worden sind, im Anschluss nicht mehr rekonstruiert werden (es sei denn der aktuelle Masterschlüssel wird zunächst exportiert und für einen späteren Zweck abgelagert). Eine entsprechende Warnung erfolgt seitens der P-Lib-UI. Bis auf dem Export/Import des Masterkeys soll der P-Lib-App-Nutzer möglichst nicht mit irgendwelchen Schlüsseln konfrontiert werden.

 

Abbildung 2: P-Lib Masterschlüssel ex- und importieren

Public-Key-Infrastucture

Die P-Lib beschränkt Hosting-Apps nicht auf die ausschließliche Kommunikation über die P-Lib bzw. von der P-Lib offerierte Kommunikationskanäle. Dennoch unterstützt die P-Lib die Initiierung sicherer, auf TLS-basierende Kommunikationsschnittstellen, da dies als wichtige Anforderung seitens vieler Entwickler formuliert wurde und hierbei oftmals falsche Konfigurationen zu Sicherheitslücken führen.

Beim erstmaligen Start der P-Lib wird ein zufälliges Schlüsselpaar im Rahmen der asymmetrischen PKI generiert. Der öffentliche Schlüssel wird in Form eines X509-Zertifikates (selbst) signiert und zusammen mit dem korrespondierenden privaten Schlüssel persistiert. Dieses X509-Zertifikat kann via P-Lib-UI sichtbar gemacht werden und in Form einer Datei (im PEM-Format) exportiert oder als QR-Code dargestellt werden. Wie unter Abbildung 3 dargestellt, werden Bestandteile des individuellen öffentlichen Schlüssels dargestellt und in Form eines QR-Codes visualisiert. Das Schlüsselpaar (öffentlicher Schlüssel in X509-Zertifikatsform sowie korrespondierender privater Schlüssel) können via P-Lib-UI durch einen neuen Schlüsselpaar ersetzt werden.

 

Abbildung 3: PKI-Menüpunkt sowie eigener PKI-Zertifikat

 

X509-Zertifikate anderer P-Lib Instanzen können als vertrauenswürdig erachtet werden, sofern diese als solche importiert werden Abbildung 4 zeigt (mittig dargestellt) als vertrauenswürdig zu betrachtende P-Lib-X509-Zertifikate anderer Instanzen. Rechts werden darüber hinaus vom zugrunde liegenden Betriebssystem als vertrauenswürdig zu betrachtende Zertifikate dargestellt.

 

 

 

Abbildung 4: Darstellung vertrauenswürdiger PLib- und vom Betriebssystem verwalteter Zertifikate

Jedes dieser gelisteten Zertifikate kann durch Auswahl näher spezifiziert werden.

Im Rahmen des TLS-Kommunikationsprotokolles weisen sich Kommunikationspartner durch Austausch derer Zertifikate aus. Hierbei unterscheidet man einseitige oder beidseitige Authentifizierung der Endknoten. Die P-Lib bietet sowohl auf ankommende Verbindungen lauschende sichere Kommunikationsknoten (ServerSockets) als auch für initiierende Kommunikation vorgesehene sichere Kommunikationsknoten (Sockets). Hierbei kann je nach Wunsch signalisiert werden, ob einseitige oder beidseitige Authentifizierung gewünscht ist und ob lediglich vom Betriebssystem als vertrauenswürdige Zertifikate (bzw. Zertifikatspfade) und/oder von der P-Lib zu betrachtende Zertifikate (bzw. Zertifikatspfade) in die Verifikation der Kommunikationspartner im Rahmen der PKI involviert werden sollen. Die Technologie dieser Verifikation unter Einschluss von Zertifikatspfaden ist in der Literatur bekannt, weshalb auf diese hier nicht eingegangen wird.

Die P-Lib-UI bietet einen Testclient und Testserver, in der der Nutzer in der Lage ist zu analysieren, ob ein Kommunikationsaufbau zu einer (anderen) P-Lib-Instanz möglich ist oder nicht, wie anhand bbildung 5 dargestellt ist.

Ebenso wie es vorgesehen ist, Zertifikate anderer P-Lib-Instanzen als vertrauenswürdig zu importieren, so dass erst dann eine Kommunikation zu diesem erlaubt ist, ist auch vorstellbar, Zertifikate von P-Service-Instanzen zu importieren, jeweils in Form von PEM-Dateien oder als durch Einscannen eines QR-Codes.

Angeforderte Kommunikationsendpunkte via P-Lib realisieren stets eine verschlüsselte Kommunikationsverbindung.

Abbildung 5: PKI-Infrastruktur testen

Access-Allow Zugriffe

Die P-Lib beschränkt Hosting-Apps nichtauf die ausschließliche Kommunikation über die P-Lib bzw. von der P-Lib offerierte Kommunikationskanäle Aus der Sicherheitsperspektive bedeutet die Existenz eines sicheren Kommunikationskanales allerdings nicht, dass private Daten des Nutzers uneingeschränkt versendet werden dürfen. Gleichzeitig sind Szenarien denkbar, in der eine App die Übertragung privater Daten vollziehen muss, unabhängig davon, ob ein Kommunikationskanal via P-Lib oder ein eigens erstellter Kommunikationskanal erstellt wird. Bspw. muss eine App die Kontaktliste mit einem Server abgleichen, sodass Chats mit bekannten Kontakten erst erfolgen kann. Ein anderes Beispiel wäre die Übertragung eines Bildes an ein soziales Netzwerk. Den Beispielen gefolgt erfolgt kein Widerspruch zu den im AppPETs gestellten Anforderungen, sofern der Nutzer über einen solchen Informationsfluss informiert ist und dieser diesen rechtzeitig unterbinden kann. In Zusammenarbeit mit der Auditierung bietet die P-Lib bestimmte Schnittstellen für den Zugriff auf private Daten. Erfolgt ein Zugriff über diese Schnittstellen, dürfen daraus resultierende, zurückgegebene (private) Daten versendet werden, ohne dass eine Auditierung auf Basis einer statischen Datenflusskontrolle dies bemängelt. Allerdings tragen jene Schnittstellen dazu bei, dass zur Laufzeit der Benutzer über die Zugriffsabsicht informiert wird. Da es sich hierbei um Funktionalitäten der P-Lib handelt, hat der App-Entwickler hierbei keinerlei Einfluss.

Am Beispiel der für eine Chat-App erforderlichen Kontaktliste muss allerdings nicht unbedingt die gesamte Kontaktliste freigegeben werden. Möglicherweise zieht es der Benutzer vornerein vor, nur eine bestimmte Kontaktmenge für einen Chat vorzusehen. Die entsprechende P-Lib-Schnittstelle für den Abruf von Kontakten sorgt zunächst dafür, dass aus der gesamten Liste aller lokalen Kontakte durch den Nutzer zur Laufzeit nur eine bestimmte, selektierbare Menge weiterverarbeitet wird, dargestellt unter Abbildung 6.

Abbildung 6: Zugang auf Kontaktliste via P-Lib

Im nächsten Schritt, der für alle von der P-Lib angebotenen Zugriffsarten auf verschiedene Typen von privaten Daten zutrifft, wird der Nutzer zur Laufzeit gefragt, ob jene Daten überhaupt (auch in späteren Verarbeitungsschritten) versendet werden dürfen, egal über welche Kommunikationskanäle. Hierbei kann der Nutzer außerhalb des Einflussbereiches des App-Entwicklers entscheiden, und in welcher Form. Weiter am Beispiel der Kontaktliste wäre denkbar, die Daten entweder in Rohform, verschlüsselt oder anonymisiert für den Fluss außerhalb des Einflussbereiches der App und somit des Nutzers freizugeben. Denkbar wäre auch eine Situation, in der die Kontaktdaten in mathematische durch Einwegfunktionen erzeugte Prüfsummen konvertiert werden, anhand auf dem Server mittels Duplikatensuche eine Herleitung zwischen zwei möglichen Chatpartnern hergestellt werden kann.

Für andere Typen von privaten Daten wäre auch eine Pseudonymisierung denkbar mit der Anforderung, jene Daten unter bestimmten Gesichtspunkten auf die Ursprungsform zu überführen (bspw. nach richterlichen Anforderung). Eine durch die P-Lib vorgenommene Pseudonymisierung beruht stets auf kryptographische Maßnahmen, die seitens deterministischer Schlüssel aus dem Masterschlüssel basieren, ebenso wie bei der Verschlüsselung von DatenAbbildung 7 zeigt die maximal mögliche Auswahl an Formen, die der Nutzer je nach Typ von privaten Daten autorisieren kann: Ablehnen oder Autorisierung in Rohform, anonymisiert, pseudonymisiert oder verschlüsselt.

 

Abbildung 7: Beispiel Bluetooth MAC-Adresse

Sowohl bei der Anonymisierung als auch bei der Pseudonymisierung muss berücksichtigt werden, dass je nach Fall eine bestimmte Datenstruktur erhalten bleiben muss. Bspw. muss bei der Anonymisierung oder der Pseudonymisierung von IPv4-Adressen beachtet werden, dass sich ergebende Datenstrukturen weiterhin in Form von vier Zahlenwerten mit den Wertebereichen ganzer Zahlen größer/gleich 0 und kleiner 256 ergeben. Deshalb variiert die Menge an mögliche Auswahlformen je nach Typ des betrachteten privaten Datums.

Dem Nutzer wird neben der Darstellung des Zugriffes auf einen bestimmten Datentyp darüber hinaus eine Zeichenkette dargestellt, die dem Nutzer die Absicht des zu autorisierenden Datenflusses erklärt, die wiederum vom Entwickler stammt. Bei der Verwendung jener P-Lib-Schnittstellen hat der Entwickler die Möglichkeit, diese Zeichenkette zu bestimmen.

Damit der Nutzer nicht bei jedem Zugriff mit möglicherweise nervigen Abfragen belästigt werden muss, kann der Nutzer per Auswahl einer Auswahlbox entscheiden, ob seine Entscheidung persistiert werden soll, sodass zukünftige Zugriffe für den jeweiligen Datentypen durch die P-Lib autonom beantwortet werden, ohne dass eine Unterbrechung seitens einer Abfrage erfolgt. In Kombination zur vom Entwickler vorgegebenen Zeichenkette wird eine solche Festlegung für zukünftige Abfragen dieser Art vollzogen. Ändert sich die Zeichenkette, so muss eine erneute Autorisierung erfolgen, da sich möglicherweise auch Beweggründe, die zuvor für eine Nutzerentscheidung beitrugen, ändern. Darüber hinaus kann der Nutzer auch entscheiden, dass eine solche persistierende Entscheidung allgemein für den Datentyp gilt oder aber auch darüber hinaus nur innerhalb der Programmstelle (anhand des Stacktraces), in der die Abfrage erfolgt.

Selbstverständlich müssen persistierte Entscheidungen seitens des Benutzers auch revidiert werden können. Über die P-Lib-UI können solche „access-allow“-Entscheidungen je nach Autorisierungstyp aufgelistet und revidiert werden. Abbildung 8 zeigt beispielhaft von links aus betrachtet mögliche Autorisierungsformen, persistierte Autorisierungen von zwei Datentypen (Bluetooth MAC und IMEI) in Rohformen, selektierte Anonymisierungsentscheidung für den Datentypen Kontakte mit zwei selektierten Kontakten und rechts in der Abbildung eine selektierte Autorisierungsentscheidung in Rohform der Subscriber-ID, welche aber nur für eine bestimmte Programmstelle definiert ist.

 

Abbildung 8: Revidierungen von persistierten Entscheidungen

 

Bei der Verschlüsselung wird das Datum als Zeichenkette Base64-codiert verschlüsselt, verliert somit die Struktur.

Hier können solche Entscheidungen Rückgängig gemacht werden. Im Rahmen der Autorisierung gilt es daher zu fordern, dass eine P-Lib-App an mindesten einer Stelle einen Aufruf der P-Lib-UI bietet.

Die Menge an möglichen Datentypzugriffen und die angebotene Formen nimmt im Projektverlauf stetig zu. Zum gegenwärtigen Zeitpunkt werden folgende Datentypen unterstützt (R = Rohform, A = anonymisiert, P = pseudonymisiert, V = verschlüsselt):

Datentyp	Beispiel	R	A	P	V	Bemerkung
Telefonnr.	+491761122334	x	x		x
DeviceId	dd29eebc9baa120c	x	x	x	X	Auch als AndroidId bekannt
Bluetooth MAC	A0:B1:C2:D3:E4:F5	x	x	x	X
Kontakte	(Max Mustermann, +491761122334), (Petra Müller, +49301122334)	x	x		x	Vorselektion möglich
IMEI	3899112233445	x	x		x
Letzter Ort	Lo: 52.51, La: 13.32, ACC: 21, ET=…, ALT=123.5	x	x
SIM Nr.	89112233445566	x	x		X
Subscriber ID	261122334455	x	x		x
Wifi Info	SSID, BSSID, Status, …	x
Wifi MAC	A0:B1:C2:D3:E4:F5	x	x	x	x

 

Wichtig: Gerade (und nicht nur) auf private Daten zugreifende API-Schnittstellen erfordern die Existenz von Betriebssystem-Permissions. Es ist Aufgabe des Entwicklers dafür Sorge zu leisten, dass diese je nach Gebrauch durch die P-Lib-App an geeigneter Stelle eingefordert werden. Unter Android müssen diese im App-Manifest deklariert werden und je nach Typ im Programmcode vor dem Zugriff (durch Nutzung der API) eingefordert werden.

 

Allow-Flow Zugriffe

Der Zugriff auf private Daten über „access-allow“-Zugriffe via P-Lib, wie es im vorigen Abschnitt dargestellt wurde, erfordert die aktive Berücksichtigung entsprechender Schnittstellen, die seitens der P-Lib angeboten werden. Bei der Konzipierung einer App können entsprechende Schnittstellen vorzeitig berücksichtigt werden. Nach Zugriff auf private Daten über jene Schnittstellen können diese im weiteren Verlauf ggf. modifiziert und über unterschiedliche Kanäle versendet werden.

Im AppPETs-Projekt wird jedoch auch das Ziel verfolgt, Hersteller bereits existierender Lösungen zu motivieren, deren Lösungen datenschutzfreundlich durch die Integration der P-Lib zu gestalten. Dies soll jedoch mit minimalem Aufwand realisiert werden können. „Allow-Flow“-Zugriffe autorisieren den Datenfluss nach außen für bereits über konventionelle Methoden erlangte private Daten beliebigen Typs. Abbildung 9 skizziert den Sachverhalt für „allow-flow“-Zugriffe.

 

Abbildung 9: „Allow-Flow“-Entscheidungen

Durch Verwendung entsprechender P-Lib Schnittstelle wird ein beliebiges Datenobjekt zusammen mit einer vom Entwickler verfassten Begründung verpackt aufgerufen mit der Folge, dass zur Laufzeit von der P-Lib und somit außerhalb des Einflussbereiches des Entwicklers eine graphische Darstellung erfolgt, wie man Abbildung 9 links entnehmen kann, in der nach Autorisierung eines Datenflusses für gegebenes Datum gefragt wird. Wie bei „access-allow“-Zugriffen kann der Nutzer zur Laufzeit jenen Fluss verbieten oder in Rohform, anonymisiert, pseudonymisiert oder verschlüsselt autorisieren, wobei die Form wiederum vom Datenobjekt selbst abhängt. Auch hier kann der Nutzer bestimmen, dass gegebene Entscheidung für einen Datentypen unter Berücksichtigung der vom Entwickler verfassten Begründung persistiert wird, sodass zukünftige Autorisierungsentscheidungen seitens der P-Lib autonom entschieden werden können. Auch kann angegeben werden, ob hierzu die aktuelle Programmstelle, an der die Autorisierungsanfrage erfolgt, von Relevanz ist oder nicht.

Selbstverständlich müssen solche Entscheidungen, wie im „access-allow“-Fall, durch den Benutzer revidiert werden können. Abbildung 9 zeigt weiterhin eine solche selektierte Entscheidung für einen Dateizugriff in Rohform, die Übersichtsseite der Typen von Entscheidungen für „allow-flow“-Datenflüsse sowie persistierte Entscheidungen, in der der Datenfluss nicht erlaubt ist.

Auch aufgrund von „allow-flow“-Zugriffsrevidierungen muss der Auditor im Rahmen des App-Audits nachvollziehen, dass die P-Lib-App in mindestens einen Punkt eine Verbindung zur P-Lib-UI bietet.

Privacy-Services (P-Services)

Der Fokus von AP 2 des AppPETs-Projektes ist die Kreierung von komplexen PETs, die zumeist in Form von entfernten Diensten (P-Services) realisiert werden. Die P-Lib bietet für den Gebrauch dieser P-Services Schnittstellen an. Je nach Fokus kapselt die P-Lib auch geeignete Mechanismen sowie die Kommunikation mit entfernten Servern, die als vertrauenswürdig erachtet werden und vom AppPETs-Konsortium kreiert werden.

Abbildung 10 zeigt die Existenz eines beispielhaftes P-Services, hier in Form einer entfernten Cloud-Storage-Lösung als Key-/Value-Datenspeicher. Der App-Entwickler, welcher ggf. Gebrauch von diesem Dienst macht, nutzt vorgegebene Schnittstellen für die Ablage von Daten (hier: „put“ zur Ablage, „get“ zur Erlangung von Datensätzen und „delete“ zum Löschen von Datensätzen). Spezifische Variationseinstellungen kann der Nutzer bei Bedarf via der P-Lib-UI vornehmen. Wie in der Abbildung dargestellt, kann dieser zum Beispiel, sofern erforderlich die Zieladresse sowie einen Port bestimmen. Die P-Lib bietet für den Dienst „Key-/Value-Datenspeicher“ auch alternative (ggf. angebundene) Lösungen an, zum Beispiel einen lokalen Speicher, einen vereinfachten JAVA-basierenden Server oder einen REST-Server. Der Entwickler muss sich aber um die Implementierung nicht kümmern, denn dies ist ihm gegenüber innerhalb der PLib abgekapselt. Und welche dieser konkreten Lösungen tatsächlich verwendet werden, liegt auch nicht in der Hand des Entwicklers.

Abbildung 10: P-Service-Einstellungen über die P-Lib

Anmerkung: Zum gegenwärtigen Zeitpunkt ist lediglich eine P-Service-Anbindung existent. Mit Fortschritt des AppPET-Projekts werden vermutlich weitere folgen.

 

App-Info

Die Sektion unter App-Info dient informellen Zwecken zu der P-Lib-App selbst, aber auch zum Gerät.

Abbildung 11: App-Info: Übersicht, App-Version, Android-Permission

Abbildung 11 stellt von links kommend zunächst die Kategorisierung von Informationen dar, die dargestellt werden können. Mittig werden Informationen zu der P-Lib-(Host)-App visualisiert. Rechts daneben werden die Android-Permissions, die die App in Anspruch nimmt bzw. nehmen könnte sowie (noch) nicht in Anspruch genommene bzw. entzogene Permissions, gelistet. Von hier aus kann man über ein Menü zur Android-Systemeinstellung gelangen, in der es dem Benutzer möglich wäre, der App bereits vergebene Permissions zu entziehen.

Abbildung 12 zeigt den Abruf gerätespezifischer Informationen und listet darüber hinaus sämtliche auf diesem Gerät installierte P-Lib-Apps. Hierzu wird keine Liste gepflegt, stattdessen verwendet die P-Lib einen bestimmten Mechanismus, um an jene Informationen zu gelangen.

Abbildung 12: App-Info: Geräte-Info, Auflistung aller P-Lib-Apps auf dem Gerät

 

Info

Der Hauptmenüpunkt „Info“ stellt wesentliche Partner im Projekt AppPETs dar.

Abbildung 13: AppPETs-/P-Lib-Info-Ansicht

Beispielhafter Einsatz der P-Lib

Nachfolgend soll anhand umgesetzter Demonstratoren der Einsatz der P-Lib beispielhaft dargestellt werden.

Einsatz der P-Lib für notwendigen Fluss privater Daten nach außen

Es wurde bereits angedeutet, dass der Fluss privater Daten in einen von der App nicht kontrollierbaren Bereich („außen“) je nach Szenario nicht immer unumgänglich ist.

Nachfolgend wird beispielhaft folgendes Szenario betrachtet: Eine App listet sämtliche Dateien im lokalen Dateisystem des mobilen Gerätes auf und bietet zur Zwecke der Sicherung selektierter Dateien die Möglichkeit, diese auf einem beliebigen Cloud-Server, hier beispielhaft Dropbox, zu sichern oder herunterzuladen. Abbildung 14 stellt wesentliche Funktionen der App dar.

Abbildung 14: Beispielhafte App: Synchronisieren von Dateien mit der Cloud

Aus der Perspektive der Privatsphäre des Nutzers fließen somit private Daten in Form von Dateien übers Netzwerk an einen dritten Server. In diesem Beispiel erfolgt der Fluss zwar durch explizite Interaktion durch den Benutzer nach außen, aber theoretisch könnte dieser Fluss auch ohne Selektion durch Nutzer und daher für diesen unsichtbar ohne Selbstbestimmung erfolgen. Programmatisch wird der Upload einer Datei, wie in Abbildung 15 links zu sehen, ohne Einfluss bestimmter Schnittstellen der P-Lib umgesetzt.

Eine im Rahmen der Auditierung für das Projekt AppPETs modifizierte Variante der App „Androlyzer“, welche eine statische Datenflussanalyse unter Einbezug von Schnittstellen der P-Lib vornimmt, stellt, rechts dargestellt, einen so genannten „Datenleck“ bzw. „Datenleak“ fest.

Abbildung 15: Datenleak: Fluss nach außen ohne Einfluss der P-Lib

Zwar wird in diesem Beispiel eine Datei nur dann auf dem Dropbox-Server hochgeladen, wenn der Benutzer es explizit möchte und darüber hinaus erfolgt der Transfer mittels der von Dropbox zur Verfügung gestellten Dropbox-API, welche für die Übertragung eine sichere, verschlüsselte Ende-zu-Ende-Verbindung initiiert, dennoch kann auf Seiten des Nutzers nicht garantiert werden, ob die auf dem Server abgelegten Dateien sicher verwaltet werden, wenngleich Dropbox es verspricht. Zumindest Administratoren von Dropbox hätten die Möglichkeit, auf jene Dateien zuzugreifen, darüber hinaus muss man sich darauf verlassen, dass keine erfolgreichen Hackerangriffe erfolgen, Zugangspasswörter nicht ausgespäht werden oder bspw. Geheimdienste oder staatliche Organisationen nicht den Betreiber dazu zwingen, hochgeladene Daten freizugeben, abgesehen davon, dass unterschiedliche Rechtsprechungen je nach Standort des Servers gelten.

Im nächsten Schritt erfolgte eine Modifikation der Implementierung der hier beschriebenen App mit folgenden Überlegungen: Dateien eines Nutzers sollen in einer dem Serverbetreiber oder Dritten nicht verwertbaren Form abgelegt werden und nur durch den Datenbesitzer verwertbar werden. Dies wird durch eine Verschlüsselung des Datenstroms realisiert. Die Verschlüsselung basiert auf einen Passwort, die dem Serverbetreiber oder Dritten nie zugänglich sein wird. Hierfür bietet die P-Lib eine entsprechende Schnittstelle, die dafür Sorge trägt, dass ein Dateistrom in einen verschlüsselten Dateistrom überführt wird, welches dann nach außen geleitet werden darf. Unter Abbildung 1 könnte man sich hierzu eine der zwei grünen Knoten von links kommend innerhalb der P-Lib-Box vorstellen. Eine programmatische Abstraktion samt Analyseergebnis ist Abbildung 16 zu entnehmen.

Abbildung 16: Fluss nach außen unter Einfluss der P-Lib (Verschlüsselung)

Die an das AppPETs-Projekt angepasste Androlyzer-App erkennt die Nutzung einer bestimmten P-Lib-Schnittstelle, die im weiteren Verlauf den Fluss nach außen autorisiert. Es sei an dieser Stelle darauf hingewiesen, dass ein weiterer Aufruf der Art upload(fi), als Datenleak erkannt worden wäre. Die Verschlüsselung des Datenstroms erfolgt ohne konkretere Angabe eines Passwortes. Dieses wird anhand des Masterschlüssels als schützenswertes Gut deterministisch bestimmt. Damit eine weitere hier aufgeführte P-Lib-App-Instanz in der Lage ist, bereits hochgeladene Dateien sinnvoll zu interpretieren (hier: zu entschlüsseln), muss dieser P-Lib-App-Instanz derselbe Verschlüsselungspasswort (im Rahmen der symmetrischen Verschlüsselung auch Entschlüsselungspasswort genannt) und demnach derselbe Masterschlüssel zugrunde liegen. Hier kann der Nutzer ggf. den Masterschlüssel aus der ersten App-Instanz importieren.

Es sind jedoch weiterhin im Szenario der Synchronisierung von Dateien mit einem Cloud-Server Variationen denkbar, in der es Sinn macht, Dateien in deren Ursprungsform auf einem entfernten Server abzulegen, bspw. damit dieser mit anderen Nutzern geteilt werden kann. Ein anderes Beispiel wäre eine App, die es dem Benutzer ermöglicht, eine aufgenommene Fotografie auf einem sozialen Netzwerk abzulegen, in diesem Fall sinngemäß unverschlüsselt. An anderer Stelle wurde in diesem Dokument bereits geäußert, dass private Daten in interpretierbarer Form nur selbstbestimmt durch den Nutzer nach außen fließen sollen. Dies impliziert, dass der Nutzer zur Laufzeit noch vor einen solchen Fluss selbstbestimmt darüber entscheiden darf, ob dieser Fluss tatsächlich stattfinden soll oder nicht.

In den Abschnitten „access-allow“ und „allow flow“ wurden Möglichkeiten dargestellt, anhand dessen der Nutzer zur Laufzeit bereits durch die App vernommene private Daten bzw. beim Zugriff auf diese, Bestimmungsrecht hinsichtlich eines Flusses nach außen ausüben darf. Auch hier kann man sich in Abbildung 1 bei „access-allow“ einen beliebigen Knoten innerhalb der P-Lib-Box und bei „allow flow“ einen der zwei von links kommenden Knoten innerhalb der P-Lib-Box vorstellen, in der beim Letztgenannten die Überführung von einem nicht zur Übertragung vorgesehenen Datenstromes in eine zur Übertragung vorgesehenen Datenstrom stattfindet. Abbildung 17 stellt letzteres Verhalten anschaulich dar.

Abbildung 17: Fluss nach außen unter Einfluss der P-Lib (Autorisierung zur Laufzeit)

Zunächst wird das private Datum (hier Referenz auf Datenstrom einer Datei) in einen Container verpackt, zusammen mit einen vom App-Entwickler verfassten Nachricht, die den Nutzer zur Laufzeit möglichst motivieren sollte, einen vorgesehenen Fluss zu autorisieren. Anschließend wird ein Callback kreiert, in der vom Entwickler implementiert werden soll, was mit dem Rückgabewert geschehen soll, bspw. dass es versendet werden soll (sofern eine Autorisierung erfolgte und demnach das Parameter einen sinnvollen Wert erhält) oder eben nicht. Zuletzt wird eine P-Lib-Schnittstelle mit dem Callback aufgerufen, welches zur Laufzeit und außerhalb des Einflussbereiches des Entwicklers eine graphische Oberfläche darstellt, in der nach Autorisierung seitens des Nutzers gebeten wird. Die zuvor verfasste Nachricht wird hierbei dem Nutzer dargestellt. Solche Entscheidungen können für zukünftige Anfragen persistiert werden (in Abhängigkeit des Hinweistextes durch den Entwickler und optional durch die Programmstelle, an der die Autorisierungsanfrage erfolgt). Demnach würde sich ein Aufpoppen einer graphischen Benutzerschnittstelle, wie in Abbildung 17 rechts dargestellt erübrigen und die Callback-Anweisung würde sofort umgesetzt. Solche permanente Entscheidungen können via P-Lib-UI nachträglich revidiert werden.

Nicht in Abbildung 17 sichtbar ist die Möglichkeit neben der Ablehnung eines Datenflusses die Autorisierung des Datenflusses in Originalform, anonymisiert, pseudonymisiert oder verschlüsselt, je nachdem ob eine Anonymisierung/Pseudonymisierung unter Erhaltung des Objektformes sinnvoll erscheint, zu wählen.

Ähnlich verhält es sich mit dem Zugriff auf private Daten über ausgezeichnete P-Lib-Schnittstellen, welche nach Erhebung in der vom Nutzer selektierten Form versandt werden dürfen.

Es stellt sich die Frage, wie es sich verhält, wenn der Entwickler zwar korrekte Schnittstellen der P-Lib verwendet, sich aber nicht an der Laufzeitentscheidung seiner Nutzer hält.

Abbildung 18: Umgehung der Nutzer-Entscheidung mittels Seitenkanal

Abbildung 18 stellt einen solchen Sachverhalt dar. Im Gegensatz zum letzten Beispiel wird der Upload einer Datei auch dann initiiert, wenn der Nutzer zur Laufzeit eine solche Entscheidung ablehnt (Else-Teil). Wie man rechts in der Abbildung 18 erkennt, ist Androlyzer in der Lage, solche „Seitenkanäle“ korrekterweise zu identifizieren.

Abbildung 19 visualisiert diesen Sachverhalt in Form eines Datenflussgraphens. Angenommen Knoten B stellt die positive Entscheidung des Nutzers dar, mit der Folge, dass der Upload im weiteren Verlauf durch Knoten C realisiert wird (Zwischenknoten stellen Anweisungsschritte innerhalb der P-Lib dar, die hier weder zu sehen sind, noch im Einflussbereich des Entwicklers liegen), sofern aber der Nutzer einer Autorisierung des Datenflusses negiert, wird im Else-Teil auf Knoten A verwiesen, welcher zur Folge hat, dass der Upload dennoch unter Knoten C erfolgt.

Abbildung 19: Umgehung der Nutzer-Entscheidung mittels Seitenkanal (Datenflussmodell)

 

Einsatz der P-Lib in Verbindung zu externen Privacy-Services

Die P-Lib zeichnet sich des Weiteren dadurch aus, dass bekannte Privacy-Services (P-Services) in Anspruch genommen werden können, zumeist für die Umsetzung komplexerer Privacy Enhancing Technologien (PETs). Nachfolgend soll ein Beispiel dargestellt werden, in der allerdings ein einfacher externer P-Service durch die P-Lib und somit durch App-Entwickler in Anspruch genommen wird.

Hierbei handelt es sich um einen Storage-Dienst in Form einer Key-/Value-Datenbank mit der Anforderung, dass der Betreiber des Dienstes weder in der Lage ist, Daten einzusehen, noch diese einem bestimmten Nutzer zuordnen zu können.

Beispielhaft sei eine ToDo-Listen-App gegeben. Diese erlaubt es dem Benutzer eine maximal fest definierte Menge x an Aufgaben anzulegen und zusammen mit dem Status der Aufgabe (offen oder erledigt) auf einem entfernten Server zu synchronisieren.

Abbildung 20: AppPETs-ToDo-Listen-App

Abbildung 20 stellt den wesentlichen Funktionsaufbau der ToDo-Listen-App dar. Hierbei gilt die Voraussetzung, dass der Betreiber des entfernten Speichers niemals in der Lage ist i) einen Datensatz einem bestimmten Benutzer/Gerät zuzuordnen und ii) Inhalte der jeweiligen Datensätze diesem unverständlich sind. Bei dem zu diesem Zweck erstellten Cloud-Storage-Server als P-Service handelt es sich um eine REST-basierenden Instanz eines Web-Servers, mit der über die P-Lib kommuniziert wird. Die Kommunikation seitens der P-Lib mit dem REST-Server zur Zwecke der Ablage eines Key-/Value-Paares erfolgt nach folgenden Schema, welches unter Abbildung 21 visualisiert wird.

Abbildung 21: P-Lib-Kommunikation zur Zwecke der Ablage eines Key-/Value-Paares

Hierbei referenziert die ToDo-Listen-App einen Datensatz mit dem Bezeichner key1, key2 bis keyX, während der Wert (Value) des Datensatz im JSON-Format transferiert wird. Da sowohl Key als auch Value schützenswerte Güter sind, erfolgt eine Verschlüsselung des Value-Wertes mit einem Schlüssel S₂ zu V während der Key in Abhängigkeit eines Schlüssels S₁ zunächst verschlüsselt und dann eine kollisionsarme Prüfsumme K berechnet wird. Beide Schlüssel S₁ und S₂ werden in Abhängigkeit des Masterschlüssels deterministisch generiert. Erst in diesen Formen wird via P-Lib der entfernte REST-Server angewiesen, jenen Datensatz, referenziert als K mit dem Wert V auf dem eigenen Speicher abzulegen.

Weiter bietet die P-Lib Schnittstellen zum Abruf eines Datensatzes, referenziert durch einen Key K an. Hierbei handelt es sich bei K wie zuvor um eine zuvor mit Schlüssel S₁ verschlüsselte und anschließend berechnete Prüfsumme der Zeichenkette „keyN“, wobei N ein positiver ganzer Zahlenwert kleiner/gleich x ist. Ein Angreifer könnte eine Brute-Force-Attacke generieren, in dem dieser bspw. die Zeichenkette „key1“ mit sämtlichen möglichen Schlüsseln erzeugen würde und jedes Mal versuchen, unter dem erzeugten Key einen zugehörigen Value-Wert V abzufragen. Jedoch ist V wiederum, sofern es der Angreifer tatsächlich schafft, einen auf dem Cloud-Server existierenden K zu finden, mit einem weiteren Schlüssel verschlüsselt, die nicht in seinem Besitz sein sollte. Da S₁ und S₂ vom Masterschlüssel deterministisch abhängen, ist dies der einzige Schutzgegenstand seitens der P-Lib, welche auch nur durch die P-Lib selbst verwaltet wird.

Die P-Lib bietet eine Schnittstelle zum Löschen eines Datensatzes, ebenfalls referenziert durch einen zu übergebenden Key-Wertes.

Die pro Nutzer/Gerät maximale Anzahl x an Einträgen kann per vorgegebener Schnittstelle erfragt werden.

Bei jedem Start der ToDo-Listen-App bzw. während der Synchronisierung erfragt die App durch den Gebrauch entsprechender P-Lib-Schnittstellen sämtliche Datensätze, referenziert durch key1, key2 bis hin zu keyX (natürlich verschlüsselt und gehashed). Zu jeden auf dem entfernten Server verfügbaren key wird der verschlüsselte Wert zurückgegeben, durch die P-Lib entschlüsselt und der ToDo-Listen-App zur Visualisierung zurückgegeben.

Der Cloud-Betreiber ist nicht in der Lage zu unterscheiden, ob zwei Datensätze von einem Nutzer/Gerät oder unterschiedlichen Nutzern/Geräten stammt.

Abbildung 22: Ex- und Import des Masterschlüssels und Auswirkungen

Abbildung 22 stellt die Auswirkung des Ex- und anschließenden Imports des Masterschlüssels im Kontext der ToDo-Listen-App dar. Hierbei wird der Masterschlüssel einer P-Lib-App-Instanz importiert, mit der zuvor seitens der ToDo-Listen-App bereits Datensätze generiert worden sind. Nach dem Importvorgang werden exakt selbe Datensätze referenziert, weshalb entsprechende Datensätze einer zuvor anderen Instanz dargestellt werden. Man beachte, dass der Ex- oder Import-Vorgang durch die ToDo-Listen-App referenziert wird (im oberen Teil der App), die Umsetzung aber außerhalb des Einflussbereiches des ToDo-Listen-App-Entwicklers realisiert wird. Die P-Lib-API bietet neben einer Schnittstelle für die Einstiegsseite der P-Lib-UI, wie zuvor unterAbbildung 1 dargestellt, direkte Referenzierungen zu bestimmten Funktionalitäten der P-Lib, wie hier zum Export oder Import des Masterschlüssels.

Abbildung 23: Referenz einer P-Lib-App zur P-Lib-UI

Abbildung 23 zeigt ein weiteres Beispiel der Verwendung einer spezialisierten UI-Schnittstelle der P-Lib, in diesem Fall zur Einstellung der Verwendung des P-Services „Key-/Value-Storage“. Darüber hinaus sieht man auch die Referenzierung zur P-Lib UI unter dem Menüpunkt „P-Lib Settings“, welcher Existenz im Rahmen der Auditierung vom Auditor zu prüfen sei.