Entwicklung einer datenschutzfreundlichen Ausführungsumgebung für Smart-Home-Dienste

Masterarbeit , 2019 , 127 Seiten , Note: 1,0

Informatik - Angewandte Informatik

In einem Smart Home werden Alltagsgegenstände miteinander vernetzt und mit Sensoren und Aktuatoren ausgestattet, um so die Lebensqualität der Bewohner zu erhöhen. Auf diese Weise werden jedoch auch viele private Daten erfasst, die, wenn sie miteinander kombiniert werden, ein Risiko für die Privacy des Nutzers darstellen und zum Nachteil des Nutzers ein-gesetzt werden können.

Mit PATRON und der PMP gibt es bereits Systeme, die den Zugriff auf bestimmte Muster beschränken, die Weitergabe der Sensordaten verhindern und die Verwendung der Aktuatoren begrenzen können. Es existiert jedoch kein System für das Smart-Home-Umfeld, das gleichzeitig Sensordaten verfremden oder blockieren, Muster in Sensordaten verschleiern und die Verwendung der Aktuatoren begrenzen kann.

Deshalb stellt diese Arbeit das Privacy-System SPYaware vor, das PATRON mit der PMP kombiniert und in das Regelverarbeitungssystem MIALinx integriert. Dabei werden das Berechtigungsrichtlinienmodell der PMP und dessen Erweiterung ACCESSORS dazu genutzt, die Sensoren und Aktuatoren zu reglementieren. Mithilfe der Zugriffssteuerung von PATRON können private Muster verschleiert werden, bevor sie das Regelverarbeitungssystem erreichen. Die Verteilung der Privacy-Einstellungen auf die einzelnen Geräte erfolgt analog zu dem Verteilungsmechanismus von AVARE.

Um die Realisierung des Konzepts anhand eines realitätsnahen Anwendungsfalls aus dem Smart-Home-Umfeld zu demonstrieren, wird SPYaware prototypisch implementiert. Die anschließende Evaluation zeigt, dass SPYaware durch die Kombination von PATRON und der PMP die Privacy des Nutzers in diesem Anwendungsfall gewährleisten kann. Die Evaluation zeigt allerdings auch, dass es nicht immer möglich ist, die Privacy des Nutzers voll-ständig sicherzustellen, ohne die Servicequalität der Anwendung zu beeinträchtigen.

Inhaltsverzeichnis

1 Einleitung
1.1 Aufgabenstellung
1.2 Gliederung

2 Anwendungsszenarien und Anforderungen
2.1 Anwendungsszenarien
2.2 Anforderungen
2.3 Einhaltung der Schutzziele

3 Verwandte Arbeiten
3.1 Privacy-Mechanismen für Smart Devices
3.2 Privacy-Mechanismen für Datenstromsysteme
3.3 Zentrale Konfigurationsmechanismen

4 Konzept
4.1 Platzierung der Privacy-Kontrolle
4.2 Komponenten von SPYaware
4.3 Adapterlogik für die Datenquellen
4.4 Privacy-Filter für die Datenquellen
4.5 Zugriffssteuerung
4.6 Verarbeitung der Wenn-Dann-Regeln
4.7 Verifikation
4.8 Privacy-Filter für die Datensenken
4.9 Adapterlogik für die Datensenken
4.10 Verteilung der Konfiguration auf die Smart Devices

5 Grundlagen
5.1 MIALinx
5.2 PATRON
5.3 PMP
5.4 ACCESSORS
5.5 AVARE

6 Implementierung
6.1 Evaluation der Teilsysteme
6.2 Privacy-Kontrolle in den Smart Devices
6.3 Privacy-Kontrolle in der IoT-Plattform
6.4 Verteilung der Privacy-Einstellungen

7 Prototyp
7.1 Anwendungsszenario
7.2 Umsetzung im Prototyp

8 Evaluation
8.1 Anforderungsevaluation
8.2 Vergleich mit verwandten Systemen
8.3 Gewährleistung der Privacy

9 Zusammenfassung und Ausblick

Kurzfassung

In einem Smart Home werden Alltagsgegenstände miteinander vernetzt und mit Sensoren und Aktuatoren ausgestattet, um so die Lebensqualität der Bewohner zu erhöhen. Auf diese Weise werden jedoch auch viele private Daten erfasst, die, wenn sie miteinander kombiniert werden, ein Risiko für die Privacy des Nutzers darstellen und zum Nachteil des Nutzers eingesetzt werden können.

Mit PATRON und der PMP gibt es bereits Systeme, die den Zugriff auf bestimmte Muster beschränken, die Weitergabe der Sensordaten verhindern und die Verwendung der Aktuatoren begrenzen können. Es existiert jedoch kein System für das Smart-Home-Umfeld, das gleich­zeitig Sensordaten verfremden oder blockieren, Muster in Sensordaten verschleiern und die Verwendung der Aktuatoren begrenzen kann.

Deshalb stellt diese Arbeit das Privacy-System SPYaware vor, das PATRON mit der PMP kombiniert und in das Regelverarbeitungssystem MIALinx integriert. Dabei werden das Be­rechtigungsrichtlinienmodell der PMP und dessen Erweiterung ACCESSORS dazu genutzt, die Sensoren und Aktuatoren zu reglementieren. Mithilfe der Zugriffssteuerung von PATRON können private Muster verschleiert werden, bevor sie das Regelverarbeitungssystem errei­chen. Die Verteilung der Privacy-Einstellungen auf die einzelnen Geräte erfolgt analog zu dem Verteilungsmechanismus von AVARE.

Um die Realisierung des Konzepts anhand eines realitätsnahen Anwendungsfalls aus dem Smart-Home-Umfeld zu demonstrieren, wird SPYaware prototypisch implementiert. Die an­schließende Evaluation zeigt, dass SPYaware durch die Kombination von PATRON und der PMP die Privacy des Nutzers in diesem Anwendungsfall gewährleisten kann. Die Evaluation zeigt allerdings auch, dass es nicht immer möglich ist, die Privacy des Nutzers vollständig sicherzustellen, ohne die Servicequalität der Anwendung zu beeinträchtigen.

Abbildungsverzeichnis

2.1 Anwendungsszenario 1

2.2 Anwendungsszenario 2

3.1 Systemdiagramm von RetroSkeleton

3.2 Sicherstellung der Identität durch ein asymmetrisches Kryptosystem

3.3 CHARIOT-Protokoll

3.4 Authentifizierungsprotoll von Gritti et al

4.1 Schematischer Aufbau von SPYaware

4.2 Platzierung der Privacy-Kontrolle

4.3 Komponenten von SPYaware

4.4 Hierarchie zur Verallgemeinerung

4.5 Blockierung seltener Werte innerhalb eines bestimmten Zeitraums

4.6 Verschleierung der Adressbuchdaten

4.7 Verschleierung des Standorts

4.8 Verteilung der Konfiguration

5.1 Architektur von MIALinx

5.2 Architektur von PATRON

5.3 Vertauschen der Ereignisse zur Verschleierung des privaten Musters

5.4 Berechtigungsrichtlinienmodell der PMP

5.5 Berechtigungsmodell in ACCESSORS

5.6 Arbeitsprinzip von AVARE

6.1 Privacy-Kontrolle in den Smart Devices durch ACCESSORS

6.2 Funktionsweise der Zugriffssteuerung

6.3 Verteilung der Privacy-Einstellungen

7.1 Anwendungsbeispiel

7.2 Fahrweg des Nutzers

7.3 Situationsabhängige Verschleierung der Position

8.1 Screenshot der Ausgabe des Prototyps

Tabellenverzeichnis

3.1 Evaluation der Privacy-Mechanismen für Smart Devices

3.2 Evaluation der Privacy-Mechanismen für Datenstromsysteme

6.1 Evaluation der Teilsysteme

8.1 Anforderungsevaluation und Vergleich mit THOR

8.2 Anteil der verschleierten und der erhalten gebliebenen Muster

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

In einem Smart Home sind Alltagsgegenstände wie Heizung, Lampen, Jalousien oder Kühl­schrank miteinander vernetzt und mit Sensoren und Aktuatoren ausgestattet [VRM+17]. Die­se Gegenstände werden dadurch zu intelligenten Geräten (engl. Smart Devices). Das Ziel ist es, die Lebensqualität und die Sicherheit der Bewohner zu erhöhen und Energie effizienter zu nutzen [DLY+06]. Die Sensoren ermöglichen die kontinuierliche Erfassung von Kontextin­formationen. Diese Kontextinformationen werden an ein Datenstromsystem gesendet, das die Daten in Echtzeit analysiert [VRM+17] und die Aktuatoren entsprechen zuvor definierter Re­geln steuert [CFS+14].

Die Sensoren und Aktuatoren können beispielsweise genutzt werden, um zu erkennen, wenn der Nutzer nach Hause kommt. Dazu wird der Standort des Nutzers mithilfe des GPS-Sensors in seinem Smartphone kontinuierlich erfasst. Durch das Internet der Dinge (engl. Internet of Things, IoT) können die Daten aus unterschiedlichen Datenquellen miteinander kombiniert werden, wodurch eine große Menge an Daten erfasst wird [CBM+15]. In diesen Daten kann das Datenstromsystem Muster erkennen [KLC02] und eine zuvor definierte Aktion auslösen. Muster sind bestimmte Abfolgen von Sensordaten, aus denen weiteres Wissen abgeleitet wer­den kann [SDM+17]. Aus den Standortinformationen kann beispielsweise das Bewegungs­muster abgeleitet werden. Bewegt sich der Nutzer auf das Haus zu, kann rechtzeitig bevor der Nutzer nach Hause kommt die Heizung eingeschaltet werden.

Die Sensoren in einem Smart Home erfassen auch viele private Daten, die, wenn sie mitei­nander kombiniert werden, ein Risiko für die Datensicherheit und die Privacy des Nutzers darstellen können [ZCW+14]. Als Privacy bezeichnet man die Fähigkeit einer Person, selbst zu bestimmen, welche persönlichen Informationen sie preisgibt und gegenüber wem sie das tut [Moo08]. Das im vorherigen Beispiel erfasste Bewegungsmuster kann über die Aktuatoren verbreitet und zum Nachteil des Nutzers eingesetzt werden. Beispielsweise könnte die Versi­cherungsgesellschaft des Nutzers anhand des Bewegungsmusters erkennen, welche Straßen der Nutzer befahren hat und ob er dabei die zulässige Höchstgeschwindigkeit überschritten hat. Das Überschreiten der zulässigen Höchstgeschwindigkeit könnte zur Erhöhung der Versi­cherungsbeiträge führen.

1.1 Aufgabenstellung

Mit PATRON [SDM+17] und der PMP [SM13] gibt es bereits Systeme, die den Zugriff auf bestimmte Muster beschränken, die Weitergabe der Sensordaten verhindern und die Verwen­dung der Aktuatoren begrenzen können. Jedoch existiert kein System für das Smart-Home- Umfeld, das gleichzeitig Sensordaten verfremden oder blockieren, Muster in Sensordaten aus mehreren Quellen verschleiern und die Verwendung der Aktuatoren begrenzen kann.

PATRON [SDM+17] ist ein Privacy-System für das Internet der Dinge. Es ergänzt die Stan­dardarchitektur für Anwendungen im Internet der Dinge um eine Verifikations- und Konfigu­rationsschicht und um eine Zugriffssteuerungsschicht. Dadurch können Muster im Daten­strom, die der Nutzer zuvor in natürlicher Sprache formuliert hat, verschleiert werden. Dabei wird sichergestellt, dass der Nutzen der Anwendung so wenig wie möglich beeinträchtigt wird [PDT+18].

Die PMP (Privacy Management Platform) [SM13] ist ein Berechtigungssystem für Mobil­plattformen, das den Zugriff der Anwendungen auf die privaten Daten des Nutzers steuert. Dazu legt der Nutzer beim ersten Start einer Anwendung fest, welche Funktionen und Daten die Anwendung nutzen darf. Dabei ist es auch möglich, der Anwendung statt den korrekten Daten randomisierte Daten unterzuschieben. Der Nutzer wird dabei über die Konsequenzen seiner Entscheidungen informiert. Mit der PMP ist es jedoch nicht möglich, Datenströme, die aus mehreren Quellen kommen, zu reglementieren.

In MIALinx [WHS+16] können Regeln definiert werden, die beschreiben, wie ein Aktuator auf ein bestimmtes Muster in den Sensordaten reagieren soll. Ziel dieser Arbeit ist es, ein Pri­vacy-System zu entwickeln, das PATRON mit der PMP kombiniert und in MIALinx inte­griert. Dieses System trägt den Namen SPYaware (Smart Home Privacy-aware Runtime En­vironment). Dazu wird ein Konzept erstellt und anschließend prototypisch implementiert, das PATRON als sichere Ausführungsumgebung für MIALinx nutzt und mithilfe des Berechti­gungsrichtlinienmodells der PMP bzw. dessen Erweiterung ACCESSORS die Sensoren und Aktuatoren reglementiert. Die zentrale Konfiguration von PATRON und der PMP erfolgt analog zu dem Verteilungsmechanismus von AVARE [AOP+17].

1.2 Gliederung

Die Arbeit ist in folgender Weise gegliedert:

Kapitel 2 - Anwendungsszenarien und Anforderungen beschreibt Anwendungsszenarien aus dem Smart-Home-Umfeld und leitet daraus Anforderungen an das zu entwickelnde System ab.

Kapitel 3 - Verwandte Arbeiten stellt verwandte Privacy-Mechanismen für Smart Devices und Datenstromsysteme vor. Außerdem werden verwandte Systeme beschrieben, mit denen Einstellungen für verschiedene Geräte zentral verwaltet werden können.

Kapitel 4 - Konzept beschreibt den Aufbau und die Funktionsweise des Privacy-Systems SPYaware. Dazu wird zunächst der schematische Aufbau von SPYaware erklärt und diskutiert, in welchen Komponenten die Privacy-Kontrolle stattfinden soll. Anschlie­ßend werden die einzelnen Komponenten von SPYaware erläutert und es wird erklärt, wie die Privacy-Einstellungen auf die einzelnen Komponenten verteilt werden können.

Kapitel 5 - Grundlagen stellt existierende Systeme vor, die zur Implementierung von SPYa- ware verwendet werden.

Kapitel 6 - Implementierung zeigt, wie die in Kapitel 5 vorgestellten Systeme kombiniert werden können, um SPYaware zu realisieren.

Kapitel 7 - Prototyp beschreibt, wie der Prototyp realisiert wird. Dazu wird zunächst ein An­wendungsbeispiel vorgestellt, das in dem Prototyp umgesetzt werden soll. Danach wird auf die Umsetzung des Prototyps eingegangen.

Kapitel 8 - Evaluation bewertet die Ergebnisse des Prototyps. Dazu wird zunächst überprüft, inwieweit SPYaware die Anforderungen aus Kapitel 2 erfüllt. Danach geht es darum, wie gut die privaten Muster verschleiert werden können und inwieweit dabei die öf­fentlichen Muster erhalten bleiben.

Kapitel 9 - Zusammenfassung und Ausblick fasst die Ergebnisse der Arbeit zusammen und bietet einen Ausblick auf zukünftige Arbeiten.

2 Anwendungsszenarien und An­forderungen

Zunächst werden in Abschnitt 2.1 Anwendungsszenarien im Bereich Smart Home beschrie­ben und die daraus resultierenden Bedrohungen für die Sicherheit und die Privacy des Nutzers aufgezeigt. Anhand dieser Szenarien werden in Abschnitt 2.2 die Anforderungen an das Da- tensicherheits- und Datenschutzkonzept abgeleitet. In Abschnitt 2.3 werden Schutzziele vor­gestellt und überprüft, ob die Anforderungen sicherstellen, dass die Schutzziele eingehalten werden.

2.1 Anwendungsszenarien

Im Smart-Home-Umfeld gibt es eine Vielzahl an Anwendungsszenarien, bei denen die Ge­währleistung der Privacy der Nutzer wichtig ist [AAL11]. In diesem Abschnitt werden zwei Anwendungsszenarien exemplarisch beschreiben.

Anwendungsszenario 1

Rechtzeitig bevor der Nutzer nach Hause kommt, soll die Heizung eingeschaltet werden, da­mit in der Wohnung eine angenehme Raumtemperatur herrscht. Kommt der Nutzer nach 17 Uhr nach Hause, soll der Backofen vorgewärmt werden, damit der Nutzer sich eine Pizza machen kann.

Dieses Szenario ist in Abbildung 2.1 dargestellt. Zunächst wird eine Möglichkeit benötigt, den Standort des Nutzers zu ermitteln, um daraus das Bewegungsmuster des Nutzers abzulei- ten. Wie in Abbildung 2.1 zu sehen, kann dazu der GPS-Sensor des Autos oder der GPS- Sensor des Smartphones des Nutzers verwendet werden. Außerdem muss es möglich sein, die Heizung und den Backofen zu steuern. Dazu wird eine zentrale Steuerung benötigt, die auf die Positionsveränderung des Autos reagiert und die Heizung und den Backofen einschalten 5 kann. Da der Backofen erst nach 17 Uhr eingeschaltet werden soll, muss außerdem die Uhr­ zeit bekannt sein.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1: Anwendungsszenario 1 Anwendungsszenario 2

Der Nutzer soll per SMS informiert werden, wenn ein Paket in der Paketbox vor dem Haus abgelegt wird. Die Benachrichtigung soll auch an das Multimediasystem im Auto des Nutzers geschickt werden. Auf diese Weise kann der Nutzer auch während der Fahrt benachrichtigt werden, wenn er das Smartphone nicht bedienen darf.

Dieses Szenario ist in Abbildung 2.2 dargestellt. Die Paketbox vor dem Haus muss erkennen können, dass ein Paket abgelegt wurde. Außerdem muss sie über eine Internetanbindung ver­fügen, um das Ereignis den anderen Systemen mitteilen zu können. Die zentrale Steuerung, die alle ankommenden Sensordaten verarbeitet und die Aktuatoren steuert, muss über eine Funktion verfügen, die das Versenden von SMS-Nachrichten erlaubt. Der Empfang der SMS­Nachricht muss sowohl mit dem Smartphone des Nutzers als auch mit dem Multimediasystem im Auto möglich sein.

Aus diesen Szenarien ergeben sich verschiedene Bedrohungen für die Sicherheit und die Pri­vacy des Nutzers:

1. Um zu erkennen, dass der Nutzer sich auf das Haus zubewegt, ist es notwendig, die aktuelle Position des Nutzers mithilfe des GPS-Sensors in seinem Smartphone oder mithilfe des GPS-Sensors des Autos zu ermitteln. Diese Informationen können miss­braucht werden, um das Bewegungsprofil des Nutzers auszuspionieren. Das Bewe­gungsmuster kann beispielsweise für einen Supermarkt interessant sein, der mithilfe des Bewegungsprofils weiß, wann der Nutzer üblicherweise einkauft und so seine Werbung zielgerichteter personalisieren kann.
2. Das Bewegungsprofil kann außerdem in die Hände eines Einbrechers gelangen, der dadurch weiß, wann der Nutzer nicht zu Hause ist und ab schätzen kann, wann der Nutzer wieder zu Hause sein wird. Erkennt der Einbrecher beispielsweise, dass der Nutzer sich auf dem Weg ins Kino befindet, weiß er, dass mit einer Rückkehr des Nutzers frühestens in zwei Stunden zu rechnen ist. Auf diese Weise kann sich der Ein­brecher sicher sein, bei seinem Einbruch nicht erwischt zu werden.
3. Das Bewegungsprofil kann auch für die Versicherungsgesellschaft interessant sein. Anhand des Bewegungsprofils kann ermittelt werden, welche Straßen der Nutzer be­fahren hat und ob er dabei die zulässige Höchstgeschwindigkeit überschritten hat. Ein häufiges Überschreiten der zulässigen Höchstgeschwindigkeit könnte zur Erhöhung der Versicherungsbeiträge führen.
4. Ein weiterer Angriffspunkt ist das Datenstromsystem, das Sensordaten empfängt und entsprechend der empfangenen Daten die Aktuatoren steuert. Die Steuerung der Aktu­atoren erfolgt über Regeln. Eine mögliche Regel wäre beispielsweise „Wenn ein Paket in die Paketbox gelegt wird, informiere den Nutzer per SMS-Nachricht“. Hat der Nut­zer keine SMS-Flatrate gebucht, können durch das Versenden vieler SMS-Nachrichten hohe Kosten entstehen. Wird der Empfängerkreis der SMS-Nachricht nicht einge­schränkt, könnte die SMS-Nachricht außerdem an einen Dieb geschickt werden, der das Paket aus der Paketbox entwenden will.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2: Anwendungsszenario 2

2.2 Anforderungen

Aus den im vorherigen Abschnitt beschriebenen Anwendungsszenarien und den beschriebe­nen Bedrohungen lassen sich nachfolgende Anforderungen ableiten. Die Anforderungen wer­den in die Gruppen Regelverarbeitung, Musterverschleierung, Reglementierung der Sensoren und Aktuatoren und Konfiguration eingeteilt.

Regelverarbeitung

A1 Wenn-Dann-Regeln

Im Smart Home befinden sich verschiedene Sensoren und Aktuatoren. Die Steue­rung der Aktuatoren erfolgt in Abhängigkeit von den Daten, die die Sensoren lie­fern. Es muss also möglich sein, Wenn-Dann-Regeln zu definieren, die beschrei­ben, wie auf ein bestimmtes Muster in den Sensordaten reagiert werden soll. Eine Regel könnte beispielsweise lauten: „Wenn sich der Nutzer auf das Haus zubewegt, dann schalte die Heizung ein“. Das Muster „Nutzer bewegt sich auf das Haus zu“ gehört in diesem Beispiel zum Wenn-Bestandteil der Regel und wird mithilfe der Daten des GPS-Sensors erkannt. Die Aktion „Heizung einschalten“ gehört zum Dann-Bestandteil der Regel und steuert die Heizung.

A2 Echtzeitverarbeitung

Die Sensordaten kommen als Datenströme aus mehreren Quellen wie beispielswei­se dem GPS-Sensor des Autos oder dem GPS-Sensor des Smartphones an. Da sich die Position des Nutzers jederzeit ändern kann, ist es notwendig, innerhalb einer be­stimmten Zeitspanne darauf zu reagieren. Kommt der Nutzer beispielsweise auf­grund einer Umleitung erst später nach Hause, darf die Heizung erst später einge­schaltet werden. Um auf solche Ereignisse reagieren zu können, ist es notwendig, die Sensordaten in Echtzeit zu verarbeiten.

Musterverschleierung

A3 Öffentliche Muster

Die Muster, die im Wenn-Bestandteil der Wenn-Dann-Regeln definiert werden, werden als öffentliche Muster bezeichnet. Um zu wissen, wann der Dann- Bestandteil der Wenn-Dann-Regeln ausgeführt werden soll, muss es möglich sein, die öffentlichen Muster im Datenstrom zu erkennen. In Anwendungsszenario 1 soll beispielsweise das Muster „Nutzer bewegt sich auf das Haus zu“ in den Daten des GPS-Sensors erkannt werden.

A4 Private Muster

Private Muster sind Muster im Datenstrom, die nicht preisgegeben werden dürfen, da sonst die Privacy des Nutzers verletzt wird. Dazu zählt in Anwendungsszena­rio 1 beispielsweise das Muster „Nutzer fährt zum Supermarkt“. Diese privaten Muster müssen aus dem Datenstrom entfernt bzw. verschleiert werden. Die Ver­schleierung der Muster muss außerdem domänenspezifisch sein. So soll die Infor­mation, dass der Nutzer nach Hause kommt, beispielsweise nur für die Heizung und den Backofen verfügbar sein. Alle anderen Geräte dürfen keinen Zugriff auf diese Information erhalten.

A5 Muster erhalten

Die öffentlichen Muster werden benötigt, um festzustellen, wann die Bedingung im Wenn-Bestandteil einer Regel zutrifft. Ohne die öffentlichen Muster ist die Steue­rung der Aktuatoren nicht möglich. Deshalb dürfen durch das Verschleiern der pri­vaten Muster die öffentlichen Muster nicht verloren gehen. Beispielsweise darf durch das Verschleiern des Musters „Nutzer fährt zum Supermarkt“ das Muster „Nutzer bewegt sich auf das Haus zu“ nicht zerstört werden.

A6 Keine False Positives

Treten durch das Verschleiern der privaten Muster neue öffentliche Muster im Da­tenstrom auf, die zuvor nicht enthalten waren, spricht man von False Positives. Tre­ten False Positives auf, hat das Einfluss auf die Auswertung der Bedingungen im Wenn-Bestandteil der Wenn-Dann-Regeln. Das kann dazu führen, dass die Aktion, die im Dann-Bestandteil der Regel festgelegt ist, fälschlicherweise ausgeführt wird. Deshalb dürfen durch die Verschleierung der privaten Muster keine False Positives entstehen. Beispielsweise darf durch das Verschleiern des privaten Musters „Nutzer fährt zum Supermarkt“ nicht das öffentliche Muster „Nutzer bewegt sich auf das Haus zu“ im Datenstrom auftreten, sofern es zuvor nicht schon enthalten war.

Reglementierung der Sensoren und Aktuatoren

A7 Sensoren reglementieren

Die genaue Fahrtroute und die genaue Geschwindigkeit des Nutzers darf nicht er­kannt werden, da ansonsten das genaue Bewegungsmuster des Nutzers ausspioniert werden kann. Wie in Abschnitt 2.1 beschrieben, kann das Bewegungsprofil für die Versicherung oder für einen Einbrecher interessant sein. Daher darf es beispiels­weise nicht erkennbar sein, dass der Nutzer Anliegerstraßen nutzt oder die Ge­schwindigkeitsbegrenzung einer bestimmten Straße überschreitet. Um das zu errei­chen, muss es möglich sein, die Weitergabe der Sensordaten zu reglementieren.

A8 Aktuatoren reglementieren

Neben der Reglementierung der Sensoren muss es auch möglich sein, Aktuatoren zu reglementieren. Um in Anwendungsszenario 2 hohe Kosten durch das Versen- den der SMS-Nachrichten zu vermeiden, muss es möglich sein, das Senden von SMS-Nachrichten zu beschränken. Beispielsweise könnte festgelegt werden, dass maximal zehn SMS-Nachrichten pro Tag verschickt werden dürfen.

A9 Feingranularität

Die vollständige Blockierung der Weitergabe der Sensordaten ist oft nicht sinnvoll, da die Sensordaten für die Auswertung der Wenn-Dann-Regeln benötigt werden. Beispielsweise werden die Daten des GPS-Sensors benötigt, um das Muster „Nut­zer bewegt sich auf das Haus zu“ zu erkennen. Anstatt die Sensordaten vollständig zu blockieren, wird eine feingranulare Reglementierung der Sensordaten benötigt, die es beispielsweise erlaubt, die Präzision der Sensordaten zu reduzieren. In An­wendungsszenario 1 reicht es aus, die Position auf 100 Meter genau zu kennen, um festzustellen, dass der Nutzer sich auf das Haus zubewegt. Durch die Reduzierung der Präzision der Sensordaten kann das genaue Bewegungsprofil verschleiert wer­den, ohne die Erkennung der Muster zu beeinträchtigen.

A10 Kontextsensitivität

Welche Daten weitergegeben werden, kann sich von Situation zu Situation unter­scheiden. Im Normalfall soll die Versicherung nicht erfahren, dass der Nutzer zu schnell gefahren ist. Kommt es jedoch zu einem Unfall, darf die zu hohe Ge­schwindigkeit nicht abgestritten werden können. Die Reglementierung der Senso­ren und Aktuatoren muss daher kontextsensitiv sein.

A11 Erweiterbarkeit

Ein Smart Home besteht aus vielen verschiedenen Sensoren und Aktuatoren. Durch den Kauf neuer Produkte kann das Smart Home um neue Sensoren oder Aktuatoren erweitert werden. Beispielsweise könnte sich der Nutzer einen intelligenten Kühl­schrank kaufen und in das bestehende System einbinden wollen. Dafür ist es not­wendig, dass sich neue Sensoren bzw. Aktuatoren einfach in das bestehende Sys­tem integrieren lassen.

A12 Datenzentriertheit

Da die meisten Nutzer keine Erfahrung mit der Definition von Privacy-Regeln ha­ben, ist es wichtig, dass die Konfiguration von SPYaware möglichst einfach ist. Die 11 Nutzer wissen zwar, welche Daten sie geheim halten möchten, jedoch nicht, welche Sensoren diese Daten erfassen. Beispielsweise weiß der Nutzer nicht, welcher Sen­sor genutzt wird, um das Muster „Nutzer bewegt sich auf das Haus zu“ zu erken­nen. Anstatt einzelne Sensoren zu reglementieren, sollte der Nutzer den Zugriff auf bestimmte Daten, wie beispielsweise die Standortdaten, einschränken können. Die Reglementierung muss daher datenzentriert erfolgen.

A13 Übertragungsfrequenz

Werden in Anwendungsszenario 1 die Standortdaten in einem kurzen Zeitraum sehr häufig abgefragt, kann daraus der exakte Standort berechnet werden. Dazu wird an­genommen, dass die unpräzisen Standortdaten einem zufälligen Standort innerhalb eines 100-Meter-Radius um den exakten Standort entsprechen. Berechnet man nun den Mittelwert der unpräzisen Standortdaten, erhält man eine sehr gute Abschät­zung des exakten Standorts. Um dies zu verhindern, dürfen die Standortdaten bei­spielsweise nur alle 30 Sekunden abgefragt werden. Es muss also möglich sein, die Übertragungsfrequenz der Sensordaten einzuschränken.

Konfiguration

A14 Zentrale Konfiguration

Die Sensoren und Aktuatoren in den vorgestellten Anwendungsszenarien befinden sich in einem heterogenen Umfeld. Die Sensoren und Aktuatoren können sich so­wohl im Smart Home, als auch in einem Auto befinden. Um die Privacy des Nut­zers sicherzustellen, muss die Konfiguration aller Sensoren und Aktuatoren aufei­nander abgestimmt sein. Daher sollte die Konfiguration der Privacy-Einstellungen an einer zentralen Stelle erfolgen und von dort auf die verschiedenen Smart Devices ausgeliefert werden.

2.3 Einhaltung der Schutzziele

Um die Datensicherheit des Konzepts zu gewährleisten, ist es notwendig, dass das Konzept bestimmte Schutzziele einhält. In diesem Abschnitt werden Schutzziele vorgestellt und darge­legt, inwiefern die Anforderungen sicherstellen, dass die Schutzziele eingehalten werden.

Die ISO 27001 [ISO13] definiert drei Schutzziele:

- Vertraulichkeit

Es muss sichergestellt werden, dass nicht autorisierte Personen oder Systeme keinen Zugriff auf die Daten erhalten.

- Integrität

Es muss sichergestellt werden, dass die Daten von Dritten nicht verändert werden.

- Verfügbarkeit

Es muss sichergestellt werden, dass der Zugriff auf die Daten autorisierten Personen oder Systemen innerhalb eines bestimmten Zeitrahmens möglich ist.

Die drei Schutzziele der ISO 27001 [ISO13] werden in der Literatur um weitere Ziele ergänzt.

Eckert [Eck13] nennt folgendes weiteres Ziel:

- Nichtabstreitbarkeit

Es muss sichergestellt werden, dass ein System, das eine bestimmte Aktion durchge­führt hat, dies nicht abstreiten kann.

Pohl [Poh04] sieht die folgenden Ziele als Unterziele der Integrität:

- Konsistenz

Es muss sichergestellt werden, dass die verarbeiteten Werte mit den tatsächlichen Werten übereinstimmen.

- Genauigkeit

Es muss sichergestellt werden, dass die Daten in der benötigten Genauigkeit vorliegen.

- Korrektheit

Es muss sichergestellt werden, dass die Daten fehlerfrei sind.

- Vollständigkeit

Es muss sichergestellt werden, dass keine Daten fehlen.

Um die Vertraulichkeit zu gewährleisten, muss sichergestellt werden, dass nur die öffentli­chen Muster preisgegeben werden. Um das zu erreichen, stellt Anforderung A4 (Private Mus­ter) sicher, dass alle privaten Muster verschleiert werden. Außerdem wird durch Anforde­rung A7 (Sensoren reglementieren) und A9 (Feingranularität) die Präzision der Sensordaten reduziert, wodurch private Informationen wie beispielsweise die exakte Position des Nutzers verschleiert werden.

Durch Anforderung A2 (Echtzeitverarbeitung) wird sichergestellt, dass ankommende Sensor­daten innerhalb einer bestimmten Zeitspanne verarbeitet werden. Dadurch wird die Verfüg­barkeit gewährleistet.

Die Nichtabstreitbarkeit ist dann gewährleistet, wenn sämtliche öffentlichen Muster erkannt werden, alle privaten Muster verschleiert werden und keine False Positives im Datenstrom auftreten. Dazu müssen die Anforderungen A3 (Öffentliche Muster), A4 (Private Muster), A5 (Muster erhalten) und A6 (Keine False Positives) erfüllt sein.

Anforderung A6 (Keine False Positives) verhindert, dass durch das Verschleiern neue Muster im Datenstrom auftreten, die zuvor nicht in dem Datenstrom enthalten waren, und gewährleis­tet so die Konsistenz. Die Genauigkeit wird durch Anforderung A9 (Feingranularität) sicher­gestellt, da durch Anforderung A9 gewährleistet ist, dass die Präzision der Sensordaten nur so weit reduziert wird, dass die Erkennung der öffentlichen Muster noch möglich ist. Die Kor­rektheit ist dann gegeben, wenn nach der Verschleierung keine privaten Muster mehr im Da­tenstrom vorhanden sind und keine False Positives auftreten. Das wird durch Anforderung A4 (Private Muster) und Anforderung A6 (Keine False Positives) gewährleistet. Die Vollständig­keit ist erfüllt, wenn nach dem Verschleiern der privaten Muster noch alle öffentlichen Muster im Datenstrom enthalten sind. Dies wird durch Anforderung A5 (Muster erhalten) sicherge­stellt.

3 Verwandte Arbeiten

In diesem Abschnitt werden verwandte Ansätze vorgestellt und bewertet. THOR [SSM18] ist ein Konzept für die Sicherstellung der Privacy der Nutzer für die Industrie 4.0. In der Indust­rie 4.0 werden die am Produktionsprozess beteiligte Systeme mit Sensoren ausgestattet und miteinander vernetzt, um mit den erfassten Daten den Produktionsprozess zu optimieren und die Produktion weitestgehend selbstständig zu organisieren. Ein möglicher Anwendungsfall wäre es, in einer Smart Factory anhand der erhobenen Sensordaten eine Abweichung selbst­ständig festzustellen und im Fehlerfall das notwendige Ersatzteil zu bestellen und einen Ser­vicetechniker zu informieren, der das Ersatzteil einbauen kann. Sind mehrere Servicetechni­ker verfügbar, soll der Servicetechniker gerufen werden, der sich am nächsten an der Maschi­ne befindet und gerade nicht mit anderen Arbeiten beschäftigt ist. Dazu ist es jedoch notwen­dig, den Standort der Servicetechniker ermitteln zu können und Zugriff auf den Kalender der Servicetechniker zu erhalten. Dadurch wird der Mensch zu einem relevanten Bestandteil des Produktionsprozesses, wodurch es notwendig wird, die persönlichen Daten vor unberechtig­tem Zugriff zu schützen [SSM18].

Um die persönlichen Daten des Nutzers schützen und dabei die Datenanalyse so wenig wie möglich zu beeinträchtigen, kombiniert THOR die PMP und PATRON miteinander. Die PMP wird genutzt, um die Sensoren zu reglementieren. PATRON ermöglicht es, private Muster in den Daten zu verschleiern. Beide Systeme werden in Abschnitt 5.2 bzw. Abschnitt 5.3 aus­führlicher erklärt. Bevor THOR eingesetzt werden kann, müssen zunächst die Privacy- Einstellungen festgelegt werden. Dazu beschreibt der Datenschutzbeauftragte bestimmte Schutzziele. Aus diesen Schutzzielen leitet ein Domänenexperte die Privacy-Regeln für die PMP und die privaten Muster für PATRON ab. Ein Datenanalyst formuliert Analyseziele, aus denen ein Domänenexperte die öffentlichen Muster folgert, die für PATRON und MIALinx benötigt werden [SSM18].

Zur Laufzeit reglementiert die PMP die Sensoren und stellt so sicher, dass nur die erwünsch­ten Daten zum Datenstromsystem gelangen. PATRON untersucht die ankommenden Daten­ströme aller Sensoren auf private Muster. Tritt ein privates Muster auf, wird es in ein neutra­les Muster umgewandelt. Ein neutrales Muster ist ein Muster, das keine Auswirkung auf die spätere Verarbeitung hat. Die von PATRON bereinigten Datenströme dienen anschließend als Eingabe für MIALinx. MIALinx erkennt die öffentlichen Muster und löst entsprechend der Wenn-Dann-Regeln die passenden Aktionen aus. Da PATRON alle Ausgaben von MIALinx mitlesen kann, kann nun verifiziert werden, ob alle relevanten Ereignisse erkannt wurden und ob alle privaten Muster erfolgreich verschleiert wurden [SSM18].

THOR ist ein Konzept, das für den Einsatz in einer Smart Factory konzipiert wurde. Für den Einsatz in einem Smart Home gibt es jedoch einige Anforderungen, die von THOR nicht ab­gedeckt werden. THOR ermöglicht zwar die Reglementierung der Sensoren, die Reglementie­rung der Aktuatoren ist jedoch nicht vorgesehen. Im Kontext eines Smart Homes ist dies je­doch notwendig, um beispielsweise die Anzahl der SMS, die pro Tag versendet werden dür­fen, einzuschränken, um so die Kosten für den Nutzer zu begrenzen.

Im Gegensatz zu einer Smart Factory sind die Nutzer eines Smart Homes keine Fachleute. Insbesondere sind in diesem Umfeld keine Datenanalysten und Datenschutzbeauftragte vor­handen, die sich mit der Definition von Analysezielen und Datenschutzzielen auskennen. Es gibt auch keine Domänenexperten, die die definierten Ziele in Muster überführen können. Daher muss die Definition der Wenn-Dann-Regeln und der Privacy-Einstellungen besonders einfach sein und soweit wie möglich softwareseitig unterstützt werden. Da die Nutzer eines Smart Homes über unterschiedliche Endgeräte verfügen können, muss die Konfiguration un­abhängig von Gerätetyp und Betriebssystem möglich sein. Die Konfiguration muss auch von unterwegs aus möglich sein, da die Nutzer sich auch außerhalb des Smart Homes befinden können.

Da der Nutzer nicht den ganzen Tag zuhause ist, müssen zur Steuerung der Aktuatoren des Smart Homes neben den Sensoren im Smart Home auch Sensoren außerhalb des Smart Ho­mes verwendet werden. Um beispielsweise zu erkennen, dass der Nutzer nach Hause kommt, können die Sensoren des Smartphones oder des Autos verwendet werden. Um die persönli­chen Informationen des Nutzers zu schützen, wird in diesem Fall jedoch ein heterogenes und verteiltes Privacy-System benötigt, das an einer zentralen Stelle konfiguriert werden kann und Geräte aus verschiedenen Bereichen mit einbezieht.

Im folgenden Abschnitt 3.1 werden Privacy-Mechanismen vorgestellt, mit denen Smart De­vices reglementiert werden können. Dies ist notwendig, um Sensordaten schon vor der Wei­tergabe an das Datenstromsystem zu verschleiern und die Verwendung der Aktuatoren einzu­schränken. Danach geht es in Abschnitt 3.2 um Privacy-Mechanismen, die zum Schutz der Daten in Datenstromsystemen eingesetzt werden. Abschnitt 3.3 beschreibt schließlich, wie Einstellungen, die über verschiedene Geräte verteilt sind, zentral verwaltet werden können.

3.1 Privacy-Mechanismen für Smart Devices

Die hier vorgestellten Privacy-Mechanismen für Smart Devices lassen sich in zwei Katego­rien einteilen. Der erste Ansatz besteht darin, das Berechtigungssystem von Android zu erwei­tern. Vertreter des ersten Ansatzes sind Apex [NKZ10], AppFence [HHJ+11], Constroid [SPH11], CRePE [CCF+12], MockDroid [BRS+11], SEAF [BAK+11], Sorbet [FBJ+12] und YAASE [RCF+11]. Der zweite Ansatz erweitert die Apps selbst um eine zusätzliche Überwa­chungskomponente, die die Einhaltung der Privacy-Regeln sicherstellt. AFP [SMA+17], AppGuard [BGH+14], Aurasium [XSA12], Dr. Android and Mr. Hide [JMV+12] und Retro­Skeleton [DC13] sind Vertreter des zweiten Ansatzes. Im Folgenden werden für jeden Ansatz zwei Privacy-Mechanismen exemplarisch erklärt. Alle vier Ansätze haben gemeinsam, dass sie auf Android basieren. Außerdem wird mit der PMP [Sta13] ein alternatives Berechti­gungssystem für Android vorgestellt, das sowohl die Anpassung der Apps als auch die Ver­änderung des Betriebssystems erfordert. ACCESSORS [SM18] ist eine Erweiterung des Be­rechtigungsrichtlinienmodells der PMP und erlaubt es, den Zugriff auf bestimmte Daten un­abhängig davon, von welchen Sensoren die Daten stammen, zu reglementieren. Die vorge­stellten Privacy-Mechanismen werden in Tabelle 3.1 miteinander verglichen.

Ein Vertreter des ersten Ansatzes ist Apex [NKZ10]. Mit Apex ist es möglich, restriktionsba­sierte Regeln zu erstellen. Eine solche Regel könnte beispielsweise die Anzahl der SMS, die pro Tag verschickt werden dürfen, einschränken. Neben der Definition solcher Bedingungen ist es auch möglich, einer App lediglich eine Teilmenge der angeforderten Berechtigungen zu genehmigen. Das Hinzufügen und Entziehen der Berechtigungen ist nicht nur bei der Installa­tion der App, sondern auch zur Laufzeit möglich. Nutzt eine App jedoch eine Funktion, für die Berechtigungen benötigt werden, die zuvor verweigert wurden, stürzt die App mit einer Fehlermeldung ab. Außerdem werden für Apex Root-Rechte benötigt, da Apex das Android­Betriebssystem verändert [Sta13].

Apex erlaubt es, einer App einzelne Berechtigungen zu verweigern. Es ist jedoch nicht mög­lich, feingranulare Bedingungen zu formulieren. Beispielsweise kann der Zugriff auf die Standortdaten erlaubt oder verweigert werden. Es ist jedoch nicht möglich, die Genauigkeit der Standortdaten einzuschränken. Zudem können die Privacy-Regeln nicht an bestimmte Situationen wie beispielsweise die Tageszeit geknüpft werden. Da Apex auf den in Android definierten Berechtigungen basiert, kann es zudem nicht erweitert werden [SM18].

Der Ansatz von MockDroid [BRS+11] besteht wie bei Apex darin, das Berechtigungssystem von Android zu erweitern. Anstatt jedoch einer App den Zugriff auf die Daten zu verweigern, erhält die App stattdessen falsche Daten. Fordert eine App bei der Installation bestimmte Be­rechtigungen an, werden diese zunächst erteilt. Der Nutzer kann dann zur Laufzeit festlegen, ob die App die korrekten Daten oder falsche Daten erhält. Fordert eine App beispielsweise Zugriff auf den Kalender oder die Kontakte an, wird vorgetäuscht, dass sich im Kalender bzw. in der Kontaktliste keine Einträge befinden. Möchte die App einen neuen Kalendereintrag oder einen neuen Kontakt anlegen, simuliert MockDroid ein volles Dateisystem, das keine weiteren Daten aufnehmen kann. Auch der Zugriff auf die Standortdaten und das Internet lässt sich mit MockDroid reglementieren. Anstatt die tatsächlichen Standortdaten bereitzustel­len, erhält die App den Hinweis, dass keine Standortinformationen verfügbar sind. Versuche auf das Internet zuzugreifen führen zu einer Zeitüberschreitung.

MockDroid macht sich dabei zunutze, dass die meisten Apps so entwickelt werden, dass sie mit der Nichtverfügbarkeit von Ressourcen umgehen können. Auf diese Weise ist es möglich, eine App zu installieren und ohne Absturz zu nutzen, ohne der App Zugriff auf sensible Daten geben zu müssen. Diese Vorgehensweise ist insbesondere dann sinnvoll, wenn eine App opti­onale Funktionen besitzt, die der Nutzer nicht verwenden möchte. Möchte der Nutzer bei­spielsweise nur eine bestimmte Adresse suchen und auf der Karte anzeigen, muss der App dafür der Standort des Nutzers nicht bekannt sein. Erst für die Navigation zu dieser Adresse werden die Standortinformationen benötigt. MockDroid unterstützt jedoch nur eine Teilmen­ge der in Android verfügbaren Berechtigungen [BRS+11]. Der Zugriff auf die Kamera oder das Mikrofon lassen sich mit MockDroid nicht reglementieren. MockDroid ist daher nicht erweiterbar. Zudem können die Bedingungen nicht an bestimmte Situationen wie beispiels­weise die Tageszeit geknüpft werden. Da es nicht möglich ist, feingranulare Bedingungen zu formulieren, verlieren einige Apps ihren Sinn. Eine App, die beispielsweise alle Tankstellen in der näheren Umgebung anzeigen soll, kann ohne Standortdaten nicht arbeiten. Wäre es möglich, die Berechtigungen feingranularer einzustellen, also der App den Standort zumin­dest auf 100 Meter genau mitzuteilen, würde das für das Anzeigen der Tankstellen in der nä­heren Umgebung ausreichen.

Ein Vertreter des zweiten Ansatzes ist AppGuard [BGH+14]. AppGuard verändert den Byte­code der Apps und erweitert sie so um die vorgegebenen Privacy-Regeln und eine Überwa­chungskomponente, die die Einhaltung der Privacy-Regeln sicherstellt. Dabei werden nur die Apps selbst verändert. Änderungen am Android-Betriebssystem sind nicht notwendig. Daher werden auch keine Root-Rechte benötigt. Durch die Änderung der Apps werden alle Metho­denaufrufe an die eingebaute Überwachungskomponente umgeleitet. Anschließend prüft die Überwachungskomponente, ob der Aufruf zulässig ist. Der Nutzer kann bei der Installation oder zur Laufzeit entscheiden, auf welche Daten die App zugreifen darf und welche Funktio­nen die App nutzen darf.

Anstatt den Zugriff generell zu erlauben oder zu verweigern, ist es auch möglich, feingranula- re Regeln zu definieren. Beispielsweise kann der Internetzugriff auf eine bestimmte Adresse beschränkt werden. Die korrekten Daten können verfälscht oder durch zufällig generierte Da­ten ersetzt werden. Es ist auch möglich, Regeln an bestimmte Kontexte wie den Standort zu knüpfen. AppGuard kann um weitere Datenquellen erweitert werden, da grundsätzlich jeder beliebige Befehl im Bytecode reglementiert werden kann [BGH+14]. Problematisch bei die­sem Ansatz ist, dass die Veränderung des Bytecodes der App gegen das Urheberrecht des Entwicklers verstößt und daher unzulässig ist [APW17].

Ein weiterer Vertreter des zweiten Ansatzes ist RetroSkeleton [DC13]. RetroSkeleton ist ein System, mit dem das Verhalten einer beliebigen App verändert werden kann, ohne Zugriff auf den Quellcode der App zu haben. Dazu werden bestimmte Methodenaufrufe in der App abge­fangen und durch den Aufruf einer anderen Methode ersetzt. Wie in Abbildung 3.1 zu sehen, definiert ein Richtlinienersteller zunächst eine Transformationsrichtlinie. Eine Transformati­onsrichtlinie enthält eine Beschreibung der alten Methoden, die ersetzt werden sollen und den Quellcode der neuen Methoden, die stattdessen aufgerufen werden sollen. RetroSkeleton ana­lysiert die ursprüngliche App und identifiziert die Methodenaufrufe, die gemäß der Transfor­mationsrichtlinie ersetzt werden müssen. Diese Methodenaufrufe werden durch Aufrufe an die in der Transformationsrichtlinie festgelegten Methoden ersetzt. Der Rest der App bleibt unverändert. Zusätzlich wird der Quellcode der in der Transformationsrichtlinie enthaltenen Methoden kompiliert. Am Ende werden die kompilierten Methoden, die Aufrufe dieser Me­thoden und die Bestandteile der ursprünglichen App zu einer neuen App zusammengefügt.

Die so erzeugte App kann auf jedem Android-Gerät ausgeführt werden. Eine Veränderung des Android-Betriebssystems oder Root-Rechte sind nicht notwendig. Im Gegensatz zu AppGuard wird die App nicht um eine Überwachungskomponente ergänzt, die die Einhaltung der Privacy-Regeln sicherstellt. Stattdessen werden beliebige Methodenaufrufe durch Aufrufe anderer Methoden ersetzt. Auch auf diese Weise kann die Einhaltung der Privacy-Regeln si­chergestellt werden. Beispielsweise kann der Aufruf der Standortdaten angefangen und die Rückgabe verändert werden. Anstatt den genauen Standort zurückzugeben, kann der Standort auch nur auf 100 Meter genau zurückgegeben werden. Auf diese Weise können feingranulare und kontextsensitive Privacy-Regeln definiert werden. Da die so definierten Privacy-Regeln nicht von den bestehenden Berechtigungen in Android abhängen, sind die Privacy-Regeln beliebig erweiterbar. Allerdings erfordern das Identifizieren der zu ersetzenden Methodenauf­rufe und das Programmieren der Methoden, die stattdessen aufgerufen werden sollen, Pro­grammierkenntnisse. Zudem verstößt die Veränderung der ursprünglichen App ohne das Ein­verständnis des Entwicklers wie bei AppGuard gegen das Urheberrecht und ist daher nicht zulässig [APW17].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.1: Systemdiagramm von RetroSkeleton, in Anlehnung an [DC13]

Die PMP (Privacy Management Platform) [Sta13] ist ein alternatives Berechtigungssystem für Android. Im Berechtigungsrichtlinienmodell der PMP besteht eine App aus Service Fea­tures. Ein Service Feature kapselt eine bestimmte Funktion der App. Ein Beispiel für ein Ser­vice Feature ist die Navigation zu einer bestimmten Adresse in einer Navigations-App. Eine Ressource ist einer Schnittstelle zu geschützten Daten oder Systemfunktionen. Ressourcen sind beispielsweise der GPS-Sensor oder die Kamera des Smartphones. Mithilfe von Privacy- Regeln kann der Nutzer festlegen, auf welche Ressourcen ein Service Feature zugreifen darf. Beispielsweise kann festgelegt werden, dass das Service Feature, das den Nutzer zu einer be­stimmten Adresse navigiert, auf die Daten des GPS-Sensors zugreifen darf. Wird der Zugriff für das Service Feature verweigert, wird das betroffene Service Feature deaktiviert. Die ande­ren Service Features der App sind davon nicht betroffen. So ist es weiterhin möglich, die Po­sition einer bestimmten Adresse auf einer Karte anzuzeigen. Mithilfe feingranularer Privacy- Regeln kann zudem festlegt werden, dass der Standort des GPS-Sensors nur auf 100 Meter genau weitergegeben wird. Es kann außerdem festgelegt werden, dass eine Privacy-Regel nur in einem bestimmten Kontext gilt. Beispielsweise kann eine Privacy-Regel nur an einem be- stimmten Ort gelten. In Abschnitt 5.3 wird die PMP ausführlicher erklärt.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3.1: Evaluation der Privacy-Mechanismen für Smart Devices

ACCESSORS [SM18] ist eine Erweiterung des Berechtigungsrichtlinienmodels der PMP, das den Zugriff auf bestimmte Daten unabhängig davon, von welchen Sensoren die Daten stammen, reglementiert. Dazu muss ACCESSORS wissen, welche Sensoren welche Arten von Daten erzeugen. Dadurch eignet sich ACCESSORS nicht nur für den Einsatz auf einem Smartphone, sondern auch für den Einsatz in einem Smart Home. Genau wie mit dem Berech­tigungsrichtlinienmodell der PMP ist es möglich, feingranulare und kontextsensitive Privacy- Regeln zu definieren. Jedoch kann das Objekt, das Zugriff auf die Daten anfordert, sowohl ein Smart Device als auch eine andere App sein. Als Datenquellen kommen andere Apps, Daten­banken oder Sensoren infrage. Aus diesen Datenquellen werden Informationen wie beispiels­weise der Standort abgeleitet. Eine Privacy-Regel legt fest, unter welchen Bedingungen ein anforderndes Objekt auf diese Informationen zugreifen darf. ACCESSORS wird in Ab­schnitt 5.4 ausführlich beschrieben.

Die vorgestellten Privacy-Mechanismen wurden alle entwickelt, um die Berechtigungen auf einem Smartphone zu reglementieren. In einem Smart Home müssen jedoch eine Vielzahl von Sensoren und Aktuatoren reglementiert werden. Da die Sensoren und Aktuatoren zusammen eine vernetzte Infrastruktur bilden, reicht die Reglementierung einzelner Sensoren nicht aus. Zudem macht es oft keinen Sinn, den Zugriff auf einen Sensorwert komplett zu unterbinden, da die Anwendung dann den erwünschten Nutzen nicht mehr erbringen kann. Stattdessen sind feingranulare Regeln notwendig, durch die beispielsweise die Standortdaten nur auf 100 Meter genau weitergegeben werden. Die Regeln sollten zudem kontextsensitiv sein, also beispielsweise nur zu einer bestimmten Tageszeit gelten. Da in einem Smart Home jederzeit neue Sensoren oder Datenquellen hinzukommen können, muss ein Privacy-Mechanismus, der die Datenquellen reglementiert, dynamisch erweiterbar sein.

Wie in Tabelle 3.1 zu sehen, erfüllt nur ACCESSORS alle Anforderungen. Mit Apex und MockDroid ist es nicht möglich, feingranulare und kontextsensitive Privacy-Regeln zu defi­nieren. Außerdem sind diese Systeme nicht erweiterbar. Im Gegensatz dazu ist es mit AppGuard und RetroSkeleton möglich, feingranulare und kontextsensitive Regeln zu definie­ren. Allerdings beruht das Prinzip beider Ansätze darauf, Methodenaufrufe innerhalb der App abzufangen und an eine Überwachungskomponente oder eine selbst implementierte Methode umzuleiten. Dieses Prinzip ist für Sensoren und Aktuatoren in einem Smart Home jedoch nicht geeignet. Somit kommen nur die PMP und deren Erweiterung ACCESSORS für die Reglementierung der Sensoren und Aktuatoren infrage. Da außer ACCESSORS keiner der Privacy-Mechanismen die Definition datenzentrierter Privacy-Regeln erlaubt, kommt nur ACCESSORS für die Reglementierung der Sensoren und Aktuatoren infrage.

3.2 Privacy-Mechanismen für Datenstromsysteme

In diesem Abschnitt werden Privacy-Mechanismen vorgestellt, mit denen die Verarbeitung von Datenströmen reglementiert werden kann. In Tabelle 3.2 werden die vorgestellten Pri­vacy-Mechanismen verglichen. Lindner und Meier [LM06] schlagen eine Architektur für Datenstromsysteme vor, die die rollenbasierte Zugriffskontrolle erweitert und so den Daten- strom vor unberechtigtem Zugriff schützt. In dieser Architektur wird anhand der Rolle, die einer Anwendung zugeordnet ist, entschieden, auf welche Daten die Anwendung zugreifen darf. Die Grundidee besteht darin, einen neuen Operator auf den Datenstrom anzuwenden, der die Datensätze aus dem Datenstrom entfernt, die nicht den Zugriffsregeln entsprechen. Auf diese Weise enthält der Datenstrom nur noch die Datensätze, auf die die Anwendung zugrei­fen darf. Dieser Ansatz hat jedoch den Nachteil, dass zunächst auch Datensätze verarbeitet werden, die später wieder aus dem Datenstrom entfernt werden müssen. Dadurch entsteht ein unnötiger Berechnungsaufwand. Außerdem kann die vorgestellte Architektur nicht mit Daten aus mehreren Datenströmen umgehen. Ein Smart Home besteht jedoch aus vielen Sensoren, die viele Datenströme erzeugen. Zudem ist das Herausfiltern ganzer Datensätze zu restriktiv, da diese Datensätze dadurch für die spätere Verarbeitung nicht mehr zur Verfügung stehen. Stattdessen sollten die Muster, die aus den Datensätzen abgeleitet werden können, nach be­stimmten Bedingungen verschleiert werden.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3.2: Evaluation der Privacy-Mechanismen für Datenstromsysteme

Carminati et al. schlagen mit ACStream [CCF+09] ebenfalls ein Modell vor, das die rollen- basierte Zugriffskontrolle erweitert. Dabei werden die Datensätze, die den Zugriffsregeln 24 nicht entsprechen, jedoch nicht erst im Nachhinein entfernt. Stattdessen wird, sobald das Da­tenstromsystem eine Anfrage erreicht, gemäß den Zugriffsregeln geprüft, ob der Zugriff voll­ständig oder nur teilweise erteilt werden darf. Darf der Zugriff nur teilweise erteilt werden, wird die Anfrage so umgeschrieben, dass im Ergebnis nur Datensätze enthalten sind, auf die die anfragende Anwendung zugreifen darf. Mit ACStream ist es möglich, feingranulare Zu­griffsregeln für die Datenströme zu definieren. Mithilfe weiterer Bedingungen kann der Zu­griff beispielsweise auf aggregierte Daten eingeschränkt werden. Jedoch arbeiten die Zugriffs­regeln in ACStream auf Attributebene und erlauben daher nicht die Verschleierung komplexe­rer Muster [SDM+18].

Nehme et al. stellen mit StreamShield [NLB+09] einen Ansatz vor, bei dem sich jeder ein­zelne Operator selbst überwacht. Dazu wird vor der Übertragung eines Datensatzes zunächst ein Metadatensatz übertragen, der beschreibt, unter welchen Bedingungen auf die Daten im Datensatz zugegriffen werden darf. Nur wenn der Operator die dort beschriebenen Bedingun­gen erfüllt, darf der Datensatz verarbeitet werden. Ansonsten muss der Datensatz verworfen werden. Da die Überprüfung der Zugriffsbedingungen in den einzelnen Operatoren stattfindet, setzt dieser Ansatz eine vertrauenswürdige Ausführungsumgebung voraus. Genau wie beim Ansatz von Lindner und Meier [LM06] werden jedoch auch hier Datensätze übertragen, die später verworfen werden, da die Prüfung der Zugriffsbedingungen erst in den Operatoren stattfindet und nicht schon vorher. Zudem vergrößert sich das zu übertragende Datenvolumen im Datenstromsystem, da zu jedem Datensatz ein weiterer Metadatensatz übertragen werden muss. Wie ACStream arbeitet StreamShield auf Attributebene, wodurch die Verschleierung komplexerer Muster nicht möglich ist.

PATRON [SDM+17] ist ein System für den Schutz privater Muster in Datenstromsystemen. Dazu werden vorab private und öffentliche Muster definiert. Die privaten Muster müssen aus dem Datenstrom entfernt werden, da sie die Privacy des Nutzers verletzen. Dabei sollen die öffentlichen Muster so gut wie möglich erhalten bleiben. In Anwendungsszenario 1 in Ab­schnitt 2.1 soll das private Muster „Nutzer fährt zum Supermarkt“ verschleiert werden. Das öffentliche Muster „Nutzer bewegt sich auf das Haus zu“ soll dabei jedoch erhalten bleiben, damit die Auswertung der Wenn-Dann-Regeln weiterhin möglich ist. Dazu erweitert PAT­RON die Standardarchitektur des Internets der Dinge [WLL+10] um eine Zugriffssteuerungs­schicht. Die erste Schicht der Standardarchitektur dient dem Zugriff auf die Datenquellen. Darüber sorgt die neue Zugriffssteuerungsschicht dafür, dass die privaten Muster aus den Da­tenströmen entfernt werden. In der Datenstromverarbeitungsschicht werden die Daten aus der vorherigen Schicht zusammengeführt und verarbeitet. Zur darüberlegenden Anwendungs­schicht gehören die Anwendungen und Dienste, die mit dem Nutzer interagieren. PATRON wird in Abschnitt 5.2 ausführlicher beschrieben.

Li et al. [LOW08], Kim et al. [KSC14], Waye [Way14] und Assam et al. [AHS12] stellen weitere Ansätze vor, bei denen der Datenstrom mithilfe von k-Anonymity, l-Diversity bzw. Differential Privacy anonymisiert wird.

Wie in Tabelle 3.2 zu sehen, arbeitet nur PATRON musterbasiert. Die anderen Systeme arbei­ten attributbasiert, was für viele Anwendungsfälle jedoch zu restriktiv ist. Durch die attribut­basierte Filterung werden mehr Daten entfernt wie nötig. Die musterbasierte Verschleierung von PATRON sorgt dafür, dass die Daten, die Teile eines privaten Musters sind, so verändert werden, dass das private Muster verschleiert wird. Dabei wird versucht, die öffentlichen Mus­ter so gut wie möglich zu erhalten. Im Gegensatz zum Ansatz von Lindner und Meier und zu StreamShield verhindert PATRON, dass private Muster übertragen werden. Außerdem kann PATRON Muster erkennen, die aus Daten bestehen, die aus mehreren Datenquellen stammen. Das ist notwendig, da es in einem Smart Home viele verschiedene Datenquellen gibt und die vom Nutzer definierten Muster sich über mehrere Datenquellen erstrecken können.

3.3 Zentrale Konfigurationsmechanismen

In diesem Abschnitt werden Systeme beschreiben, mit denen Einstellungen, die sich auf ver­schiedene Geräte oder Nutzer beziehen, zentral verwaltet werden können. Das Active Direc­tory ist ein Verzeichnisdienst, das Informationen über verschiedene Nutzer, Geräte und Res­sourcen in einem Unternehmensnetzwerk enthält. Ressourcen sind beispielsweise Speicher­platz, Zugriffsrechte auf Verzeichnisse, Netzwerkdrucker oder Anwendungen. Mithilfe des Active Directory können die Administratoren in einem Unternehmen definieren, auf welche Ressourcen ein bestimmter Nutzer zugreifen darf. Die Administratoren können beispielsweise festlegen, dass nur die Nutzer in der Personalabteilung auf das Verzeichnis zugreifen dürfen, in dem die Personaldaten der Mitarbeiter gespeichert sind. Die Daten des Active Directory sind in einer verteilten relationalen Datenbank gespeichert [Hau17].

Die Active Directory Rights Management Services (AD-RMS) sind Teil des Active Direc­tory. Mithilfe der AD-RMS ist es möglich, Dokumente unabhängig vom Speicherort vor un­berechtigtem Zugriff zu schützen. Zwar können die Administratoren mithilfe des Active Di­rectory festlegen, dass nur Nutzer in der Personalabteilung auf das Verzeichnis zugreifen dür­fen, in dem die Personaldaten der Mitarbeiter gespeichert sind. Jedoch kann ein Nutzer in der Personalabteilung ein Dokument aus diesem Verzeichnis in ein anderes Verzeichnis kopieren, auf das auch andere Nutzer Zugriff haben. In diesem Fall können auch unberechtigte Nutzer auf das Dokument zugreifen. Deshalb wird eine Rechteverwaltung wie die AD-RMS benötigt, die an das Dokument selbst und nicht an einen bestimmten Speicherort gebunden ist. Dazu weisen die Administratoren einer bestimmten Nutzergruppe bestimmte Rechte an einem Do­kument zu. Beispielsweise kann allen Nutzern in der Personalabteilung erlaubt werden, die Personalakte eines bestimmten Mitarbeiters zu lesen. Dazu wird das Dokument mithilfe eines Zertifikats verschlüsselt. Möchte ein Nutzer in der Personalabteilung das Dokument öffnen, erwirbt er über den Rechteverwaltungsserver eine Lizenz, die das Öffnen des Dokuments er­laubt. Dabei stellt der Server die Authentizität des Nutzers mithilfe des Active Directory si­cher und prüft, ob der Nutzer berechtigt ist, die entsprechende Lizenz zu erwerben [Hau17].

Das Simple Network Management Protocol (SNMP) ist ein Protokoll zur Überwachung und Steuerung von Geräten in einem Netzwerk wie beispielsweise Router, Switches, Server oder Drucker durch eine zentrale Administrationskomponente. Das Protokoll regelt die Kommunikation zwischen der Administrationskomponente und den einzelnen Netzwerkgerä­ten. Auf den Geräten läuft dazu eine Software, die den Zustand des Geräts erkennen und de­ren Einstellungen verändern kann. Das SNMP definiert neun Nachrichtentypen, mit denen die Administrationskomponente den Zustand der Netzwerkgeräte abfragen und Befehle an die Geräte senden kann. Mithilfe der Befehle GET, GET-NEXT und GET-BULK kann die Ad­ministrationskomponente den Zustand eines Geräts auslesen. Beispielsweise kann die Admi­nistrationskomponente auf diese Weise den Netzwerknamen eines Routers abfragen. Der SET-Befehl ermöglicht es der Administrationskomponente einen Parameter des Geräts zu ändern. Beispielsweise kann die Administrationskomponente mithilfe des SET-Befehls die IP-Adresse eines Servers ändern. Nachdem das Gerät den GET- oder SET-Befehl verarbeitet hat, sendet es eine RESPONSE-Nachricht an die Administrationskomponente. Die RESPON- SE-Nachricht enthält die Informationen, die durch den GET-Befehl angefordert wurden bzw. eine Bestätigung, dass der gewünschte Parameter verändert wurde. Die RESPONSE- Nachricht kann auch eine Fehlermeldung enthalten, falls das Abrufen bzw. das Verändern des Parameters nicht möglich ist [MS05].

Eine TRAP-Nachricht ermöglicht es dem Netzwerkgerät, unaufgefordert Informationen an die Administrationskomponente zu senden. Kommt es bei einem Gerät zu einem Hardwaredefekt wie beispielsweise einem kaputten Lüfter, kann das Gerät dies der Administrationskomponen­te mithilfe einer TRAP-Nachricht mitteilen. NOTICATION-, INFORM- und REPORT­Nachrichten sind spezielle TRAP-Nachrichten, die genutzt werden können, um Informationen zwischen unterschiedlichen Administrationskomponenten auszutauschen. Im Gegensatz zu einer TRAP-Nachricht muss eine INFORM-Nachricht vom Empfänger bestätigt werden. Im Gegensatz zum Active Directory werden die Einstellungen der Netzwerkgeräte nicht zentral auf der Administrationskomponente gespeichert und dort verteilt. Stattdessen werden die Ein­stellungen eines Netzwerkgeräts auf dem jeweiligen Gerät gespeichert und mithilfe des SNMP-Protokolls ausgelesen und verändert [MS05].

[...]

• Hochschule: Universität Stuttgart
• Note: 1,0
• Erscheinungsjahr: 2019
• Seiten: 127
• Katalognummer: V1313307
• ISBN (PDF): 9783346793249
• ISBN (Buch): 9783346793256
• Sprache: Deutsch
• Schlagworte: entwicklung, ausführungsumgebung, smart-home-dienste