© 2015 Springer. This is the author’s version of the work. It is posted at https://opencms.uni-stuttgart.de/fak5/ipvs/departments/as/publications/stachch/dasp_15_sdc.pdf by permission of Springer for your personal use. Notfor redistribution. The definitive version was published in In: Mitschang, B. et al. (Hrsg.) Datenbank-Spektrum, Band 2. SpringerNature Switzerland AG, pp. 109–118, 2015, doi: 10.1007/s13222-015-0189-y.

Datenbank-Spektrum: Data Management for MobilityDOI 10.1007/s13222-015-0189-y

Der Secure Data Container (SDC)Sicheres Datenmanagement für mobile Anwendungen

Christoph Stach · Bernhard Mitschang

Received: 28.Februar 2015 / Accepted: 12.Mai 2015 / Published: 23. Juni 2015

Zusammenfassung Mobile Endgeräte wurden zu MarcWeisers Computer des 21. Jahrhunderts, da sie als dau-erhaft verfügbare Informationsquelle Einzug in unserenAlltag gehalten haben. Auf ihnen treffen private Daten(z. B. Fotos) auf Kontextdaten (z. B. Standortdaten); ver-knüpft stellen diese ein immenses Sicherheitsrisiko dar.Wie eine Vielzahl an Datendiebstählen belegt, reichen dieexistierenden Datensicherheitssysteme für Mobilplattfor-men bei weitem nicht aus. Daher bedarf es einer Identi-fikation möglicher Angriffsvektoren sowie einer Analyseder speziellen Schutzziele eines solchen Systems. Dar-auf basierend wird die Privacy Management Platform,ein Berechtigungssystem, mithilfe des neu eingeführtenSecure Data Containers zu einem ganzheitlichen Daten-sicherheitssystem erweitert. Dabei zeigt sich, dass dieseKombination alle Schutzziele erfüllt und dennoch hoch-performant ist. Obwohl die vorgestellten Prototypen aufAndroid basieren, ist das Konzept auch auf andere App-Plattformen anwendbar.

Schlüsselwörter Datenschutz · Schutzziele · PMP-Erweiterung · Datencontainer · Evaluation

1 Einleitung

Marc Weisers Vision vom Computer des 21. Jahrhun-derts [Weiser(1999)]wurde, Dank der großen technischenFortschritte im Bereich der mobilen Endgeräte, Wirklich-keit [Schmidt and Cohen(2013)]. Da die Leistung heuti-

Diese Arbeit wurde durch Google unterstützt.

C. Stach, B. MitschangIPVS / AS Universität StuttgartUniversitätsstraße 38D-70569 StuttgartE-Mail: Christoph.Stach@ipvs.uni-stuttgart.deE-Mail: Bernhard.Mitschang@ipvs.uni-stuttgart.de

ger mobiler Endgeräte (häufig als Smart Devices bezeich-net) stetig ansteigt, sie immer längere Stand-by-Zeitenhaben und sie dennoch in die Hosentasche passen, stehtuns überall und jederzeit ein vollwertiger PC zur Ver-fügung. Mithilfe eines Smart Devices haben wir Zugriffauf eine nahezu unbegrenzte Datenquelle – das Internet.Smart Devices bieten aber noch mehr Funktionen: Da diedarin integrierten Sensoren (z. B. der GPS-Empfänger)unentwegt Daten sammeln, ist ein Smart Device nicht nureine Informationssenke, sondern gleichzeitig eine Daten-quelle. Der Kontext des Anwenders kann so möglichstexakt erfasst werden, um daraus Rückschlüsse auf die ge-genwärtige Situation, in der der Anwender sich befindet,zu ziehen. Dieses Wissen steht allen Anwendungen, dieauf dem mobilen Endgerät ausgeführt werden, (den soge-nannten Apps) zur Verfügung. Dadurch können sich diesebestmöglich auf die Bedürfnisse des Anwenders anpas-sen [Shilton(2009)]. Somit treffen auf einem Smart Devi-ce die beiden größten Bedrohungen für den Datenschutzaufeinander: Eine übersteigerte Datensammelwut seitensder Apps [Leontiadis et al.(2012)] und die Vermischungund Verknüpfung von Daten aus den unterschiedlichstenDomänen [Gaff et al.(2014)].Diese Informationen können Apps untereinander na-

hezu unbeschränkt austauschen. Die Servicequalität so-wie der Leistungsumfang einer App werden erheblichgesteigert, wenn diese sich autonom mit allen benötig-ten Daten versorgen können. Dieser technologische Fort-schritt stellt allerdings gleichzeitig eine neue Gefahren-quelle dar: Die große Anzahl an privaten Daten aus denunterschiedlichsten Anwendungsbereichen, die jeder Appbeinahe uneingeschränkt zur Verfügung stehen, machendiese Geräte zu einem Angriffsziel. Seit 2012 steigt dieAnzahl an bösartiger Schadsoftware kontinuierlich an:Die Angreifer zielen dabei auf unterschiedliche Datenab, angefangen bei (scheinbar) harmlosen Informationen

https://opencms.uni-stuttgart.de/fak5/ipvs/departments/as/publications/stachch/dasp_15_sdc.pdfhttps://opencms.uni-stuttgart.de/fak5/ipvs/departments/as/publications/stachch/dasp_15_sdc.pdfhttps://opencms.uni-stuttgart.de/fak5/ipvs/departments/as/publications/stachch/dasp_15_sdc.pdfhttps://doi.org/10.1007/s13222-015-0189-y

110 Christoph Stach, Bernhard Mitschang

über das System, über die Standortdaten bis hin zu per-sönlichen Daten [Svajcer(2014)]. Studien belegen, dass20 von 30 populären Apps aus Google Play sensiblenDaten missbrauchen, z. B. indem sie sie an Werbeanbie-ter weiterleiten [Enck et al.(2014)]. Darüber hinaus kom-men Smart Devices in immer mehr Anwendungsberei-chen zum Einsatz, wie dem Gesundheitssektor (z. B. mit-tels Smart Watches [Felizardo et al.(2014)]) oder in derIndustrie 4.0 [Gorecky et al.(2014)]. Die dabei entstehen-den Daten sind in besonderem Maße schützenswert.Mobilplattformanbieter sehen sich daher verstärkt mit

der Problematik konfrontiert, wie der Datenschutz tech-nisch gewährleistet werden kann. Die Lösungen der Key-player Apple und Google sind jedoch nicht zufriedenstel-lend, da sie entweder den (häufig) unerfahrenenAnwenderüberfordern (Android OS) oder ihm jedwede Entschei-dungsfreiheit und Kontrolle über seine Daten nehmen(iOS) [Posegga and Schreckling(2011)].Daher beschäftigen sich viele externe Entwickler-

teams damit, wie ein Datensicherheitssystem für Mo-bilplattformen aussehen sollte. Die bisherigen Untersu-chungen der Autoren haben ergeben, dass neben u. a.einer feingranularen und kontextsensitiven Zugriffskon-trolle der Anwender in besonderem Maße berücksichtigtwerden muss. Da dieser in der Regel kein IT Experte ist,darf ein Datensicherheitssystem nicht zu kompliziert seinund es muss ihn jederzeit umfassend über die Auswir-kungen seiner Einstellungen auf das Verhalten der Appsinformieren [Stach and Mitschang(2013)]. Basierend aufdiesen Anforderungen entstand die PrivacyManagementPlatform (PMP), ein alternatives Berechtigungssystemfür Android [Stach(2013a)]. Dieses reine Berechtigungs-system soll nun zu einem Datensicherheitssystem erwei-tert werden, um somit den Schutz der privaten Datenweiter zu verbessern. Die wichtigsten Ergebnisse diesesArtikels lassen sich mit den folgenden drei Punkten zu-sammenfassen:

(𝐼) Initial wird eine Definition von „Datenschutz“ ge-geben und daraus Schutzziele für ein Datensicherheits-system abgeleitet und Angriffsvektoren identifiziert.

(𝐼𝐼)Ausgehend von diesen Schutzzielenwirdmit demSecured Data Container (SDC) eine Komponente zur si-cheren Speicherung sensibler Daten als Erweiterung fürdie PMP eingeführt. Der SDC erlaubt allerdings nicht nureine sichere Speicherung von sensiblen Daten, sondernermöglicht zusätzlich einen einfachen, aber dennoch si-cheren Austausch von Daten zwischen mehreren Apps.Durch eine vollständige Verschlüsselung der Daten kannsichergestellt werden, dass nur solche Apps Zugriff darauferhalten, die zuvor vom Anwender dazu legitimiert wur-den. Der SDC besitzt weitere Sicherheitsmaßnahmen, wiebeispielsweise einen sogenannten Kill Switch zur siche-ren Löschung der gespeicherten Daten für den Fall einer

Kompromittierung oder eine aggregierte (und damit ein-geschränkte) Sicht auf die Daten.

(𝐼𝐼𝐼) Abschließend werden PMP und SDC evaluiertund die Messergebnisse mit den Messungen auf einer un-veränderten Android-Mobilplattform verglichen.Der weitere Beitrag ist wie folgt gegliedert: In Ab-

schnitt 2 wird eine Definition des Begriffs „Datenschutz“gegeben. Durch die Identifikation von relevanten Schutz-zielen sowiemöglichenAngriffsvektorenwird aufgezeigt,inwiefern diese Arbeit über den Datenschutz im enge-ren Sinne hinausgeht. Abschnitt 3 beschreibt die PMPkurz. Bedingt durch die auf eine einfache Erweiterbar-keit ausgelegte Architektur der PMP, lässt sich der SDCsehr einfach in diese integrieren. Details hierzu sowie zuden Funktionen, die von SDC unterstützt werden, wer-den in Abschnitt 4 beschrieben. Im Anschluss daran folgteine Evaluation der PMP und des SDCs in Abschnitt 5.Abschließend wird in Abschnitt 6 ein Überblick über Da-tensicherheitssysteme für Mobilplattformen gegeben unddie mit dem SDC erweiterte PMP mit dem Stand der For-schung verglichen, bevor Abschnitt 7 eine Zusammenfas-sung dieses Beitrags liefert.

2 Datenschutz – rechtliche und technische Sicht

Es gab einen großen Aufschrei in der Bevölkerung, alsEdward Snowden aufdeckte, dass sogar staatliche Behör-den (u. a. die NSA) Apps zu Spionagezwecken verwen-den. Hierzu konnten (scheinbar) harmlose Apps, wie bei-spielsweise das Spiel Angry Birds, dazu missbraucht wer-den, um äußerst private Informationen über die Anwenderaufzusammeln. Zu diesen Daten gehören beispielsweisederen politische Ansichten oder deren sexuelle Orientie-rung [Larson et al.(2014)]. Aufgewühlt von diesen beun-ruhigenden Fakten, forderten viele Anwender bessere Da-tenschutzmaßnahmen [Balebako et al.(2013)].„Datenschutz“ wird (zumindest für die Europäische

Union) in Artikel 8 derCharta der Grundrechte der Euro-päischen Union1 definiert. So muss jede Person die Mög-lichkeit haben, alle personenbezogenen Daten, die sie be-treffen, zu schützen. Unter demSchutz versteht die Charta,dass eine Vereinbarung zwischen dem Anwender und derApp getroffen wird, in der geregelt ist, welche persönli-chen Daten zu welchem Zweck von der App verarbeitetwerden. Artikel 2 der Europäischen Datenschutzkonven-tion2 verfeinert dabei, was unter Verarbeitung verstandenwird: Das Speichern von Daten, das Durchführen logi-scher und / oder rechnerischer Operationen mit diesenDaten sowie das Verändern, Löschen, Wiedergewinnenoder Bekanntgeben von Daten.

1 http://goo.gl/L8aKeE letzter Zugriff am 05.06.20152 http://goo.gl/yW8hm3 letzter Zugriff am 05.06.2015

Der Secure Data Container (SDC) 111

Anhand dieser Definition wird klar, dass das Vorge-hen von Angry Birds nicht gegen die Charta verstößt: DerAnwender wird bei der Installation einer App aus GooglePlay darüber informiert, auf welche Daten diese zugrei-fen kann. Stimmt der Anwender diesen Zugriffen nicht zu,so wird die App nicht installiert und infolgedessen sinddie persönlichen Daten weiterhin geschützt. Somit wirdder Charta vollständig entsprochen. Allerdings ist diesaus Anwendersicht keine zufriedenstellende Lösung. Wiedas Angry Birds Beispiel eindrucksvoll zeigt, kann derAnwender häufig nicht absehen, welche potentielle Ge-fahr aus der Kombination von scheinbar harmlosen Infor-mationen ausgehen kann. Außerdem wird der Anwendermit einer Flut von Berechtigungsanfragen überschüttet, sodass er nicht in der Lage ist, die wirklich relevanten Anfor-derungen herauszufiltern [Felt et al.(2012a)]. So bedarf esbeispielsweise einerGenehmigung, dass eineApp dasGe-rät vibrieren lassen darf, wodurch keine Gefährdung fürden Anwender ausgeht.Ferner wird der Anwender nur sehr allgemein über die

Verwendung der Daten informiert. Er erfährt weder, wel-che Informationen eine App genau anfragt, noch was siedamitmacht.Nur eineÜbersicht,welcheGruppen vonDa-ten von einer App verarbeitet werden können, wird gene-riert. Die READ_PHONE_STATE-Berechtigung erlaubtbeispielsweise, dass eine App Zugriff auf diverse Infor-mationen über das mobile Gerät bekommt. Dies kann da-zu verwendet werden, um beispielsweise zu erkennen, obgerade ein Telefonat geführt wird und gegebenenfalls dieAudioausgabe der App vorübergehend einzustellen. Diegleiche Berechtigung ermöglicht es einer App aber auch,dass sie die IMEI-Nummer (International Mobile Stati-on Equipment Identity) oder die Telefonnummer auslesenkann, was wiederum eine erheblich größere Gefährdungfür die Privatheit des Anwenders darstellt. Die Berechti-gungen, denen ein Anwender zustimmen muss, um eineApp verwenden zu können, stellen also in der Regel nureine Obermenge der tatsächlich benötigten Rechte dar.Außerdem führt die Tatsache, dass der Anwender ohne-hin allen Berechtigungen zustimmen muss, wenn er eineApp verwenden will, dazu, dass er sich nicht spezifischdamit auseinandersetzt, sondern blind allen Zugriffen zu-stimmt [Felt et al.(2012b)]. Im Folgenden sollen daherrelevante Schutzziele, die über den reinen Datenschutzhinausgehen, identifiziert und mögliche Angriffsvektorenbeschrieben werden.

2.1 Schutzziele

Einerseits steigt die Anzahl an aggressiver Adware aufmobilen Plattformen, d. h. Apps, die ihre vom Anwen-der erteilten Berechtigungen dazu missbrauchen, um pri-vate Daten unbemerkt an Werbenetzwerke weiterleiten

(z. B. für personenbezogeneWerbeeinblendungen); ande-rerseits nimmt auf diesen Platformen ebenfalls die An-zahl an Malware zu, d. h. Schadsoftware, die illegal aufBenutzerdaten zugreift [Lookout(2014)]. Daher stellt dieDatensicherheit ein multidisziplinäres Problem dar, dasnur gelöst werden kann, wenn juristische Regulierungenund technische Maßnahmen nahtlos ineinander greifen.Die technische Umsetzung muss vollständig anwender-orientiert sein, damit dieser das System richtig verstehenund nutzen kann [Gerber et al.(2015)]. Die ISACA3 iden-tifiziert drei wesentliche Schutzziele:

(𝑎) Vertraulichkeit (confidentiality) stellt sicher, dass nurautorisierte Instanzen Zugriff auf Daten haben.

(𝑏) Intaktheit (integrity) garantiert, dass die Daten nichtvon Dritten kompromittiert werden können.

(𝑐) Verfügbarkeit (availability) gewährleistet, dass dieDaten jederzeit verfügbar sind.

Diese drei Grundschutzziele werden von Cherdantsevaund Hilton um weitere ergänzt, von denen im Bereichder mobilen Plattformen die folgenden von Relevanzsind [Cherdantseva and Hilton(2013)]:

(𝑑) Nachvollziehbarkeit (auditability) regelt, dass alleAktionen von Apps persistent und unüberwindbarüberwacht werden.

(𝑒) Authentizität (authenticity) überprüft die Identitätder Instanzen, die Daten anfordern.

(𝑓) Nachweisbarkeit (non-repudiation) belegt, dass eineInstanz bestimmte Daten verarbeitet hat (bzw. garan-tiert, dass dies nicht der Fall war).

(𝑔) Privatheit (privacy) gibt demAnwender die Kontrolleüber seine Daten; dies sollte nutzerzentrisch sein, d. h.Konsequenzen, die sich aus bestimmten Einstellungenergeben, müssen nachvollziehbar sein.

Nachdem die Schutzziele identifiziert wurden, die fürDatensicherheit durch technische Maßnahmen unterstütztwerden müssen, wird im Folgenden besprochen, wie An-greifer diese Schutzziele kompromittieren können. Dieaufgeführten Angriffe stellen dabei jeweils nur ein mög-liches Angriffsszenario dar.

2.2 Angriffsvektoren

Ein Angriff auf die Vertraulichkeit (𝑎) und Intaktheit (𝑏)von Daten kann dadurch erfolgen, dass diese Daten direktauf einer tieferen Schicht des Betriebssystems angefragtwerden. Wie in Abb. 1 zu sehen ist, sind Apps klar vonden Systemfunktionen getrennt. Dazwischen existiert ei-ne Schicht, die Schnittstellen für kontrollierte Zugriffe aufdie darunterliegenden Schichten (und damit auch auf die

3 http://goo.gl/1c1iN letzter Zugriff am 05.06.2015

112 Christoph Stach, Bernhard Mitschang

Application

Schicht

Apps von Drittanbietern

Trusted

Software

Schicht

OS Schicht

Bibliotheken, Laufzeitumgebung, Kernel

SQLiteSystemdaten

& -funktionenKamera …

Privacy Management Platform

Res1 Resn…

Standort

Bestimmung

App1 Appm…

Systemanwendungen

System

App1

System

Appp

…

Abb. 1 Einbettung der PMP in die Systemarchitektur

Daten) zur Verfügung stellt. Berechtigungssysteme grei-fen auf dieser Schicht ein und reglementieren hier denZugriff auf die Schnittstellen. Erlangt ein Angreifer hin-gegen direkten Zugriff auf den Kernel des Systems, so istdas Berechtigungssystem ausgehebelt und sämtliche Da-ten können uneingeschränkt gelesen und verändert wer-den. Eine andere Möglichkeit, um Zugriff auf geschützteDaten zu erlangen, stellt ein Angriff auf die Authentizität(𝑒) dar. EinAngreifer gibt vor, dass er eine vertrauensvolleInstanz ist, um so das System zu täuschen. Dazu müssendie Identifikationsmerkmale einer anderen Instanz über-nommen werden.Die Nachvollziehbarkeit (𝑑) und die Nachweisbarkeit

(𝑓) können durch beide oben beschriebenen Angriffsvek-toren ausgehebelt werden.Wenn die App eines Angreifersauf einer tieferen Schicht ansetzt, so kann ein Berechti-gungssystem diese App weder überwachen, noch derenHandlungen protokollieren. Gibt sich die App eines An-greifers als eine andere Instanz aus, so kann ein Berech-tigungssystem die App zwar überwachen, jedoch werdendie falschen Berechtigungen (d. h. die Berechtigungen deranderen App) angewandt. Auch können sämtliche Hand-lungen der App zwar nachvollzogenwerden; diese werdenaber der anderen App zugeschrieben.Die Verfügbarkeit (𝑐) kann durch Denial of Service

Angriffe beeinträchtigt werden, d. h. ein Angreifer fragtwiederholt Daten an, um das System so zu überlasten.Hierdurch sind zwar keine Daten in Gefahr, aber die Nutz-barkeit des Systems wird stark eingeschränkt.Die Kombination aus den oben beschriebenen An-

griffsvektoren schränken die Privatheit (𝑔) ein. Da esbei der Privatheit in erster Linie darum geht, dem An-wender die volle Kontrolle über seine Daten zu geben,könnte ein Angreifer diese zusätzlich schädigen, indemer das Berechtigungssystem direkt außer Betrieb setzt.Wenn das Berechtigungssystem nicht mehr arbeitet, sokann der Anwender keine Einstellungen mehr vornehmenoder (schlimmer noch) er kann zwar Einstellungen tätigen,diese werden aber vom System nicht mehr umgesetzt.Abschnitt 3 beschreibt, wie die PrivacyManagement

Platform (PMP) [Stach and Mitschang(2014)] die Schutz-ziele erfüllt. Anschließendwird inAbschnitt 4 dieArbeits-weise des SecureDataContainers (SDC) beschrieben underörtert, wie dieser Angriffe verhindert.

3 Die Privacy Management Platform

Das Regelwerk der PMP basiert auf der Überlegung, dassApps an sich keine Berechtigungen benötigen, sondernnur bestimmte Funktionen innerhalb einer App. DieseFunktionen werden logisch zu sogenannten Service Fea-tures zusammengefasst. Sämtliche Daten, auf die dieseService Features zugreifen können, werden von Informa-tionsvermittlern, den Resources, angeboten. Thematischzusammengehörige Ressourcen können in Gruppen, denResource Groups, gebündelt werden. Der Anwender kannin der PMP Regeln aufstellen (Policy Rule), die beschrei-ben, welches Service Feature unter welchem Kontext Da-ten von einer Ressource erhalten soll. Zusätzlich kanner Einstellungen vornehmen (Privacy Settings), um dieDaten, die die Apps von den Ressourcen erhalten zu an-onymisieren, zu verfremden oder gänzlich zu randomisie-ren [Stach(2013b)]. Damit die PMP eine App in dieserWeise vollständig reglementieren kann, muss die App zu-sätzliche Metadaten bereitstellen, z. B. eine Spezifikationder Service Features. Wie die PMP mit Legacy Apps ver-fährt, d. h. Apps, die dieseMetadaten nicht zur Verfügungstellen, ist in [Stach(2015)] beschrieben.Abb. 2 zeigt die Funktionsweise der PMP. Installiert

ein Anwender eine neue App (𝑁)& (1), so registriert sichdiese automatisch bei der PMP (2). Die PMP informiertden Anwender darüber, welche Service Features die Appanbietet und welche Berechtigungen (Zugriffe auf Res-sourcen) diese benötigen (𝐹 ). Der Anwender wählt aus,welche der Service Features initial aktiviert werden sollen(3). Eine Besonderheit der PMP ist es, dass neue Ressour-cen bei Bedarf sogar zur Laufzeit nachinstalliert werdenkönnen (4). Dadurch kann der Funktionsumfang der PMPjederzeit erweitert werden (z. B. durch den SDC), wie inAbschnitt 4 gezeigt. Benötigt eine App geschützte Daten,so fragt sie diese bei der PMP an (5), die darauf in demRegelwerk nachschaut, ob es eine entsprechende Regeldafür gibt (6). Anschließend wird der Zugriff auf die Da-ten erlaubt (respektive verboten) (7). Wird der Datenzu-griff untersagt, wird der Anwender darüber informiert, sodass er Regelanpassungen vornehmen kann, wenn er dasService Feature dennoch verwenden will (𝐹 ). Erhält eineApp Zugriff auf die Daten, so sammelt die Ressource dieDaten (8), nimmt, abhängig von den Privacy Settings, nö-tige Aggregationen oder Verfremdungen vor und schicktdie Daten anschließend an die App (9). Für weitere In-formationen zur PMP sei an dieser Stelle auf die entspre-chende Literatur verwiesen [Stach and Mitschang(2013),Stach(2013a)].Die PMP ist in erster Linie ein stark erweitertes Be-

rechtigungssystem. Der Anwender kann Apps feingranu-lar an seine Bedürfnisse anpassen und so die Menge derpreisgegebenen Daten auf ein Minimum reduzieren. Die

Der Secure Data Container (SDC) 113

GU

I

App

GU

I

PMP

GU

IPrivacy

Policy

Privacy

Setting

OS(z.B. Android)

App

Service

Feature1

Service

FeaturemGU

I

…

Resource Group

Resource1 Resourcen…

(1) Installation

(2) Registrierung

(3) Initiale

Regeln

(4) Download von

fehlenden

Ressourcen

(8) Zugriff auf

private Data(5) Daten-

anfrage

(6) Anfrage

an Policy(7) Datenzugriff

erlauben / verbieten

Abb. 2 Funktionsweise der PMP

Privatheit (𝑔) wird demnach vollständig gewährleistet.Die Authentizität (𝑒) einer App wird mittels der Android-Signatur, die bei der Registrierung überprüft wird, sicher-gestellt. Nur registrierte Apps können die PMP nutzenund somit Zugriff auf die Daten der Ressourcen erlangen(Vertraulichkeit (𝑎) und Intaktheit (𝑏)). Die Nachvollzieh-barkeit (𝑑) und dieNachweisbarkeit (𝑓)wird dadurch rea-lisiert, dass jede Anfrage an eine Ressource vom Systemerfasst und in einer Log-Datei hinterlegt wird. Die Ver-fügbarkeit (𝑐) hängt von der jeweiligen Ressource ab. Dasämtliche Daten i. d. R. direkt aus dem Android-Systemstammen, muss dieses deren Verfügbarkeit garantieren.Auch wenn die unterschiedlichen Prototypen der PMP

für Android umgesetzt worden sind [Stach(2013b)], sohandelt es sich bei der PMP um eine zusätzliche Schichtin der Systemarchitektur, die zwischen den Apps und demeigentlichen System sitzt (siehe Abb. 1); durch diese ge-nerische Struktur ist es möglich, die PMP auch für an-dere App-Plattform, wie etwa die Facebook Platform, zurealisieren. Da Systemanwendungen vom Plattformanbie-ter aus Performanz- und Stabilitätsgründen grundsätzlichnicht reglementiert werden sollten, beschränkt sich diePMP auf die Kontrolle von Drittanbieter-Apps. Somitkann die PMP insbesondere die Schutzziele (𝑎), (𝑏) und(𝑓) nur dann erfüllen, wenn das darunterliegende Systemnicht kompromittiert werden kann und es technisch nichtmöglich ist, über den Kernel Zugriff auf die Daten derRessourcen zu erlangen.

4 Der Secure Data Container

Für ein sicheres Datenmanagement in mobilen Anwen-dungen reicht ein reines Berechtigungssystem, wie es diePMP darstellt, allerdings nicht aus. Aus diesem Grundwird mit dem SDC ein verschlüsselter Datencontainerals Erweiterung für die PMP eingeführt. In diesem ge-nerischen Container kann jede App ihre Daten speichern.

Zusätzlich bietet der SDC die Möglichkeit, dass die Da-ten mit allen, nur mit bestimmten oder mit keinen Appsgeteilt werden. Intern speichert der SDC alle Daten alsKey-Value-Paare in einer SQLite-Datenbank ab. Durchdieses generischeDatenmodell wird größtmögliche Flexi-bilität garantiert. Nach außen lässt sich der SDC über eineSchnittstelle ähnlich der originalen Android SQLite APIansprechen. Allerdings muss beim SDC eine App nichtextra einen Content Provider (mit allen damit verbunde-nen Sicherheitsrisiken, siehe [Ongtang et al.(2012)]) fürden Datenaustausch implementieren, sondern kann direktbei der Erzeugung das Datum im SDC hinterlegen und an-geben, welche Apps Zugriff auf diesen Datenbankeintragerhalten sollen. Die Vorgehensweise bei einer Anfrage istin Abb. 3 abgebildet und wird im Folgenden detailliert:

Sobald eine App eine Verbindung zu dem SDC auf-baut, prüft der SDC, ob diese App bereits bei ihm re-gistriert ist. Wenn das nicht der Fall ist, vergibt er derApp eine eindeutige interne ID und legt einen neuen Ein-trag in der sdc_maintenance_apps-Tabelle an. Diese IDwird dazu verwendet, um den Besitzer eines Datensatzeszu identifizieren (owner-Eintrag). Standardmäßig ist nurder Besitzer eines Datensatzes dazu berechtigt, auf dieseDaten zuzugreifen. Da ein unkontrollierter Informations-fluss zwischen verschiedenen Apps, wie es bei AndroidUsus ist, eine Bedrohung hinsichtlich Information Secu-rity darstellt, unterstützt der SDC einen sichereren ModusOperandi für den Datenaustausch. Der Besitzer der Datenkann diesemit einer sharable-Flag versehen,wenn einDa-tensatz mit anderen Apps geteilt werden soll. Daraufhinerzeugt der SDC in der sdc_maintenance_share-Tabelleeinen Eintrag, welcher Datensatz mit welcher App (oderwelchen Apps) geteilt werden kann. Danach können alleApps, die vom Datenbesitzer angegeben wurden, auf diegeflaggten Daten lesend zugreifen. Aus Sicherheitsgrün-den hat nur der Besitzer Schreibrechte auf den Daten. Dasinterne Datenmodell des SDCs ist in Abb. 4 abgebildet.

114 Christoph Stach, Bernhard Mitschang

apps-Tabellen-

LookupDB-Entschlüsselung App registriert?

App-ID vergebenDatentabellen-

Lookup

App Besitzer der

Daten?

Nein

Datenrückgabe

DB-Verschlüsselung

Daten mit App

geteilt?

share-Tabellen-

LookupNein

Ja

Zurückweisung

der Anfrage

Nein

Ja

Ja

Abb. 3 SDC-Anfragealgorithmus als Aktivitätsdiagramm

Um illegale Datenzugriffe ausschließen zu können,verschlüsselt der SDC alle gespeicherten Daten, wohin-gegen Android-Datenbanken standardmäßig vollständigunverschlüsselt als Klartext gespeichert sind! Hierzu wirdeine AES-256-Verschlüsselung verwendet, wobei auch je-der andere Verschlüsselungsalgorithmus möglich wäre.Einzig der SDC besitzt den Schlüssel; die Daten werdennur dechiffriert, wenn eine App die benötigten Zugriffs-rechte hat. Der SDC stellt über die beiden Hilfstabellenzusätzlich sicher, dass eine App nur auf die eigenen odermit ihr geteilten Daten zugreifen kann. Die Daten sind nurzum Zeitpunkt eines Zugriffs unverschlüsselt. Als weitereSicherheitsmaßnahme verfügt der SDC über einen soge-nannten Kill Switch. Im Falle einer Kompromittierungkann der Anwender damit den Schlüssel löschen, wo-durch die im SDC gespeicherten Daten unlesbar werden(vgl. [Geambasu et al.(2011)]). Da mittels forensischerAnalyse einer Datenbank selbst gelöschte Datensätze wie-derhergestellt werden können [Stahlberg et al.(2007)], be-nötigtman zumLöschen des Schlüssels einVerfahren,wiees in [Reardon et al.(2012)] vorgestellt wird.Dieses eignetsich aber nur für kleinere Dateien; für ganze Datenbankenkann es nicht verwendet werden.Der SDC unterstützt die PMP in mehreren Schutzzie-

len: Selbst wenn eine App über OS-Exploits Zugriff aufdie SDC-Datenbank erhält, so sind darin alle Daten ver-schlüsselt und somit ohne den Schlüssel, der nur für denSDC zugänglich ist, weder lesbar (𝑎) noch veränderbar(𝑏). Da damit Daten nur über die PMP erlangt werdenkönnen, kann diese auch alle Zugriffe erfassen (𝑑) undprotokollieren (𝑓). Da mehrere SDC-Instanzen gleichzei-tig verwendetwerden können, können dieDaten einerAppbeispielsweise auf mehrere SDC aufgeteilt werden odereiner App ein eigener SDC zugeteilt werden, um die dau-erhafte Verfügbarkeit zu garantieren (𝑐). Die Schutzziele(𝑒) und (𝑔) werden bereits durch die PMP ausreichenderfüllt, wie in Abschnitt 3 dargestellt, und bedürfen somitkeiner weiteren Unterstützung durch den SDC. Darüberhinaus ist es möglich, für unterschiedliche SDC-Instanzenunterschiedliche Verschlüsselungsalgorithmen anzuwen-

_id (INTEGER)PS

value (TEXT)

owner (INTEGER)FK

sharable (INTEGER)

_id (INTEGER)PS

appname (TEXT)

entry (INTEGER)PS

FK

app (INTEGER)PS

FK

1

1..*

1

1..*

1

1..*

key (TEXT)

sdc_main

sdc_maintenance_share

sdc_maintenance_apps

Abb. 4 SDC-Datenmodell in UML-Notation

den. Dadurch kann, abhängig davon, wie sicherheitskri-tisch die gespeicherten Daten sind, die Performanz desSDCs aufwandsabhängig angepasst werden. Wie die Er-gebnisse aus Abschnitt 5 zeigen, überzeugt der SDC hin-sichtlich Performanz selbst mit AES-256-Verschlüsselungund stellt, trotz der erhöhten Sicherheit, das klassischeAndroid-System in den Schatten, wenn Daten mit ande-ren Apps geteilt werden.

5 Evaluation des SDCs

Die Messungen wurden auf einem unmodifiziertenNexusOne Dev Phone (1 GHz, 512 MB RAM, Andro-id 2.3.6) durchgeführt. Die Test Suite besteht aus von-einander getrennten Schreib- und Lesetests. Beide Testsarbeiten auf unterschiedlich großen Datenbeständen, an-gefangen bei kleinen Datenbeständen (𝐾) mit 500 Daten-bankeinträgen geht es über 1.000, 2.000, 4.000 und 8.000Einträgen zu großen Datenbeständen (𝐺) mit 16.000 Ein-trägen in Anlehnung an den TestIndex Benchmark vonMcObject4. Zunächst erzeugt der Schreibtest die jeweili-ge Anzahl an zufälligen Datensätzen und speichert diese.Ein Datensatz besteht dabei jeweils aus einem Schlüssel-Wert-Paar. Da der Overhead des SDCs hauptsächlichdurch Berechtigungsanfragen und Verschlüsselungsauf-gaben erzeugt wird, würde ein komplexeres Datenmo-dell dem SDC eher zu Gute kommen, da dann dieseVorlaufkosten im Vergleich zu den Abfragekosten ver-nachlässigbar werden würden. Anschließend greift derLesetest auf alle Datensätze in einer zufälligen Reihen-folge zu. Beide Tests wurden auf vier unterschiedlicheArten implementiert: als Android-App ohne Verwen-dung der PMP (Android), als PMP-App ohne Verwen-dung der SDC-Ressource (PMP), als PMP-App unterVerwendung einer SDC-Ressource ohne Verschlüsse-lung (SDC𝑈𝑉 ) und als PMP-App unter Verwendung

4 http://www.mcobject.com/android letzter Zugriff am05.06.2015

Der Secure Data Container (SDC) 115

Tabelle 1 Benchmark Ergebnisse für sehr kleine (K) repektive große (G) Datenbestände (siehe Abb. 5 für Zwischenschritte)

Schreibtest LesetestAndroid PMP SDC𝑈𝑉 SDC𝐴𝐸𝑆 Android PMP SDC𝑈𝑉 SDC𝐴𝐸𝑆

Lauf- K 25, 7 s 25, 3 s 25, 3 s 37, 3 s 17, 8 s 19, 3 s 16, 4 s 76, 4 szeit G 790, 0 s 784, 6 s 795, 4 s 1.206, 6 s 1176, 6 s 581, 5 s 440, 7 s 532, 9 s

CPU- K 13, 78% 13, 05% 14, 01% 15, 00% 6, 95% 9, 07% 16, 10% 38, 50%Auslastung G 15, 01% 14, 56% 14, 63% 15, 46% 34, 64% 22, 05% 18, 37% 22, 02%Speicher- K 9, 69MB 8, 70MB 8, 48MB 8, 77MB 13, 08MB 13, 70MB 13, 76MB 13, 53MBverbrauch G 10, 07MB 10, 61MB 11, 39MB 11, 02MB 38, 87MB 21, 48MB 18, 91MB 18, 54MB

DB- K 29 kB 39 kB 29 kB 39 kBGröße G 813 kB 1.054 kB 813 kB 1.054 kBApp-Größe 248, 51 kB 345, 06 kB 344, 24 kB 381, 82 kB 247, 06 kB 344, 78 kB 344, 27 kB 344, 42 kB

einer SDC-Ressource mit AES-256-Verschlüsselung(SDC𝐴𝐸𝑆). Beide Tests wurden für jede App 10-mal wie-derholt. Nach jedem Durchlauf wurden die Datenbanksowie der Cache vollständig gelöscht, um eine Beeinflus-sung durch warme Caches ausschließen zu können. DieErgebnisse für die kleinen (500 Einträge) und großen Da-tenbestände (16.000 Einträge) sind für den Schreib- so-wie den Lesetest in Tabelle 1 sowie Abb. 5 abgebildet.Dabei wurden die Laufzeit der App, die mittlere CPU-Auslastung, der maximale Speicherverbrauch, die Größeder Datenbank und die Größe der jeweiligen Test-App be-trachtet. Die Referenzwerte in den Tabellen sind die Me-diane aus den Testläufen, um eine Verzerrung der Messer-gebnisse durch Ausreißer auszuschließen. DieMessungenliefern zahlreiche Erkenntnisse:

1. Für die Laufzeit des Schreibtests spielt es nahezukeine Rolle, ob dieser unter Android, der PMP oder derPMP mit einem SDC ausgeführt wird. Erst wenn bei demSDC die Verschlüsselung aktiviert wird, entsteht hierbeiein Overhead. Allerdings ist AES-256 auch eines der si-chersten (und rechenintensivsten) Kryptographieverfah-ren und sollte daher auch nur für sehr vertrauliche Datengenutzt werden. Beim Lesetest können die PMP und ganzbesonders der SDC ihre Stärken ausspielen.WerdenDatenmit anderen Apps geteilt, so ist der Einsatz von ContentProvidern sehr kostenintensiv. Während man dies mit derPMP bereits auf ein Minimum reduzieren kann, könnenApps ihre Daten in einem SDC direkt untereinander aus-tauschen; trotz der höheren Sicherheit, erzielt man einenPerformanzgewinn.

2. Die mittlere CPU-Auslastung (berücksichtigt wur-den jeweils sämtliche Prozesse, die mit den Tests in Ver-bindung stehen) beim Schreibtest ist auf allen Systemennahezu gleich. Beim Lesetest zeigt sich, dass für sehrwenige Anfragen die Kosten für Berechtigungsanfragenund Dechiffrierung erheblich bemerkbar machen. Dieserelativieren sich allerdings für sehr viele Anfragen. Auf-grund der Kosten für die Content Provider bei Android,

ist die mittlere CPU-Auslastung bei der PMP sowie beidem SDC in diesem Fall deutlich günstiger.

3.Betrachtetman denmaximalenSpeicherverbrauchzur Laufzeit, so liegen beim Schreibtest alle Systeme dichtbeieinander. Beim Lesetest machen sich bei steigenderAnzahl an Anfragen die kostenintensiven Content Pro-vider bemerkbar, wodurch die PMP und der SDC etwa50% weniger Speicher benötigen. Dabei werden im Fallder PMP und des SDCs jeweils die kumulierten Kostenbetrachtet, d. h. die Kosten für die App, die PMP und dieverwendeten Ressourcen. Etwa 70% davon werden vonder PMP und den Ressourcen verursacht. Eine Instanzder PMP kann allerdings beliebig viele Apps verwalten,wodurch sich im Realbetrieb dieser Speicher-Overheadauf alle diese Apps aufteilt.

4. Die Größe der Datenbank ist unter Androidund der PMP identisch; bei dem SDC entsteht durchdie zusätzlichen Spalten in der eigentlichen Daten-tabelle sowie durch die benötigten Verwaltungstabel-len (sdc_maintenance_apps und sdc_maintenance_share)hingegen ein Overhead. Dieser Verwaltungs-Overheadliegt im Mittel bei ca. 30% und fällt, je mehr Daten einerApp in der Datenbank gespeichert werden. Jedoch selbstbei einem für eine App bereits sehr großen Datenbestandvon 16.000 Einträgen, liegt der Speicherbedarf für dieseHilfstabellen bei unter 0, 25MB.

5. Auch der Overhead der App-Größe ist mit unter150 kB gering. Dieser Overhead wird in erster Linie durchdie Definition der Service Features erzeugt. Da bei einer„richtigen“ App sich das Verhältnis App-Code zu Ser-vice Feature-Definition im Vergleich zu diesen Test-Appserheblich zu Gunsten des App-Codes entwickeln würde,wird dieser Overhead weiter relativiert.Die Kennzahlen für exponentiell wachsende Daten-

sätze sind in Abb. 5 dargestellt. Hierbei werden die Er-kenntnisse 1. bis 3. weiter gestützt. Insgesamt lässt sichfesthalten, dass sich der Einsatz eines SDCs besondersdann eignet, wenn Daten mit anderen Apps geteilt wer-den müssen. In diesem Fall erzielt man einen erheblichen

116 Christoph Stach, Bernhard Mitschang

0

5

10

15

20

500 1.000 2.000 4.000 8.000 16.000

La

ufz

eit

(in

Min

ute

n)

# Datensätze

Android PMP SDC (UV) SDC (AES)

(a) Laufzeit (Schreibtest)

0

5

10

15

20

500 1.000 2.000 4.000 8.000 16.000

La

ufz

eit

(in

Min

ute

n)

# Datensätze

Android PMP SDC (UV) SDC (AES)

(b) Laufzeit (Lesetest)

0

5

10

15

20

500 1.000 2.000 4.000 8.000 16.000

CP

U A

usla

stu

ng

(in

%)

# Datensätze

Android PMP SDC (UV) SDC (AES)

(c) Mittlere CPU-Auslastung (Schreibtest)

0

10

20

30

40

50

500 1.000 2.000 4.000 8.000 16.000

CP

U A

usla

stu

ng

(in

%)

# Datensätze

Android PMP SDC (UV) SDC (AES)

(d) Mittlere CPU-Auslastung (Lesetest)

0

2

4

6

8

10

12

500 1.000 2.000 4.000 8.000 16.000

Sp

eic

herv

erb

rau

ch

(in

MB

)

# Datensätze

Android PMP SDC (UV) SDC (AES)

(e) Maximaler Speicherverbrauch (Schreibtest)

0

10

20

30

40

500 1.000 2.000 4.000 8.000 16.000

Sp

eic

herv

erb

rau

ch

(in

MB

)

# Datensätze

Android PMP SDC (UV) SDC (AES)

(f) Maximaler Speicherverbrauch (Lesetest)

Abb. 5 Grafische Übersicht der Messergebnisse aus Tabelle 1 für eine exponentiell wachsende Anzahl an Datensätzen

Vorteil hinsichtlich Laufzeit, CPU-Auslastung und Spei-cherverbrauch. Außerdem zeigt der Vergleich zwischendem unverschlüsselten SDC und dem SDC, der AES-256verwendet, dass es sinnvoll ist, SDCs mit unterschiedli-chen Kryptographiealgorithmen zu verwenden, um Da-ten je nach Geheimhaltungsstufe und Verwendungszweckadäquat zu schützen.ModerneMehrprozessorsysteme un-terstützen die Ver- und Entschlüsselung.Neben dieser rein performanzorientierten Evaluati-

on muss in zukünftigen Arbeiten geprüft werden, obdas Modell des SDCs sämtliche Angriffsvektoren aus-reichend abgedeckt (z. B. mittels risikobasierten Sicher-heitstests [McGraw and Potter(2004)]) sowie, ob die Im-plementierung realen Angriffen standhält (z. B. mittels

Penetrationstests [Arkin et al.(2005)]). Obwohl erste Nut-zertests der PMP positiv ausfielen und der SDC für denAnwender transparent agiert, muss dieser Eindruck durchkommende Usability-Tests verifiziert werden.

6 Verwandte Arbeiten

Im Folgenden wird ein Überblick über repräsentativeDatensicherheitssysteme für Mobilplattformen gegeben.Insbesondere wird dabei auf die Schutzziele aus Ab-schnitt 2.1 geachtet: (𝑎) Vertraulichkeit, (𝑏) Intaktheit,(𝑐) Verfügbarkeit (𝑑) Nachvollziehbarkeit, (𝑒) Authentizi-tät, (𝑓) Nachweisbarkeit sowie (𝑔) Privatheit.

Der Secure Data Container (SDC) 117

Backes et al. [Backes et al.(2013)] stellen mit App-Guard ein Berechtigungssystem für Android vor. DerAppGuard App-Konverter baut in jede App eine Sicher-heitsbibliothek ein. Potentiell gefährliche Datenzugriffesind nach der Konvertierung nur über diese AppGuard-Bibliothek möglich. Allerdings ist die Manipulation vonBytecode aus zwei Gründen als kritisch zu betrachten: Ei-nerseits muss man sich dabei auf Heuristiken und Annah-men verlassen, um die relevanten Codefragmente iden-tifizieren zu können. Eine falsche Annahme kann aller-dings unvorhersehbare Effekte nach sich ziehen. Ande-rerseits bewegt sich ein solcher Konverter in einer ju-ristischen Grauzone, da u. a. § 14 UrhG (Entstellung desWerkes) oder § 303𝑎 (Datenveränderung) durch solch tief-greifende Eingriffe in den Programmfluss verletzt werdenkönnen. Aus diesem Grund wurde die App SRT App-Guard Pro aus Google Play entfernt. Daher wählt Au-rasium [Xu et al.(2012)] eine andere Herangehensweise.Hierbei wird nicht die App selbst verändert, sondern siewird in eine sichere Sandbox eingebettet und darin aus-geführt. Zur Laufzeit überwacht die Sandbox jeden Da-tenzugriff und greift gegebenenfalls ein. Im Gegensatzdazu erweitern Conti et al. [Conti et al.(2012)] das exis-tierende Android Berechtigungssystem um kontextbasier-te Regeln. Mit ihrem System CRêPE kann der AnwenderSituationen definieren, in denen bestimmte Regeln geltensollen (z. B. dass auf Standortdaten nur in der Freizeitzugegriffen werden darf). Während diese Systeme ver-suchen, die Zugriffsrechte von Apps zu reglementieren,sehen Russello et al. [Russello et al.(2011)] unter Andro-id die unkontrollierbare Weitergabe von Berechtigungen,die sogenannte Permission Escalation, als größtes Pro-blem an. In deren System YAASE wird daher ein neuesRegelsystem eingeführt, das Apps daran hindert, Berech-tigungen untereinander auszutauschen.

Während diese Systeme reine Berechtigungssystemedarstellen, verstärkt Samsung KNOX [Samsung(2015)]die Sicherheitsfunktionen auf jeder Schicht des Andro-id Software Stacks, angefangen bei einem sicheren Boot-loader, über Erweiterungen im Linux Kernel bis hin zugetrennten Speicherbereichen in der Anwendungsschicht.Virtual Fort Knox [Holtewert et al.(2013)] befasst sichmitden Sicherheitsproblemen von Firmen, die Mobilgerätein deren Unternehmen einsetzen. Virtual Fort Knox bieteteine Middleware, die sämtlichen Datenverkehr zwischeneinem Mobilgerät und dem Unternehmensnetzwerk ab-sichert. Damit stellt Virtual Fort Knox einen wichtigenSchritt in Richtung Industrie 4.0 dar. In erster Linie de-finiert es allerdings eine sichere Infrastruktur für Unter-nehmen und lässt denAnwender weitestgehend außen vor.Tabelle 2 beinhaltet die wesentlichen Erkenntnisse dieserempirischen Studie der verwandte Arbeiten. Dieser Ver-

gleich ergibt, dass die PMP in Kombination mit dem SDCdas einzige ganzheitliche Datensicherheitssystem ist.Alternative Ansätze befassen sich mit einer Analy-

se von Apps, da Google Apps vor der Veröffentlichungnicht umfassend prüft wodurch Schadsoftware in Goo-gle Play gelangt. Aus Anwendersicht ist eine Vorabprü-fung unbefriedigend: 1. Aufgrund der großen Anzahl antäglich erscheinenden (und damit zu prüfenden) Apps,verzögert sich deren Veröffentlichung. 2. Eine Vorselekti-on schränkt die Entscheidungsfreiheit der Anwender ein.Wird die Prüfung hingegen auf die Endgeräte verlagert,bleibt der Anwender in Kontrolle. Mittels einer Echtzeit-analyse des Kontroll- [Chan et al.(2012)] sowie Informa-tionsflusses [Kodeswaran et al.(2012)], kann das Verhal-ten einer App überwacht und das Gefährdungspotentialeingeschätzt werden. Ebenfalls kann auf Crowd-basierteRatingsysteme [Jin et al.(2013)] zurückgegriffen werden,um das Vertrauen in eine App zu bestimmen. Neisse etal. [Neisse et al.(2013)] stellen ein Rahmenwerk vor, mitdem dieVerarbeitung vonDaten kontrolliert werden kann,nachdem diese das Gerät verlassen haben. Dies liegt al-lerdings außerhalb des Fokus dieser Arbeit.

7 Zusammenfassung

Den Besitzern von Smart Devices wird durch die stei-gende Anzahl an Datendiebstählen mehr und mehr be-wusst, dass sie Schutzmaßnahmen treffen müssen. Be-trachtet man allerdings bestehende Datensicherheitssys-teme für Mobilplattformen, so lassen sich zwei Trendsbeobachten: Entweder werden die Anwender vollständigbevormundet oder völlig überfordert. Auch tragen die An-bieter der Mobilplattformen nur wenig dazu bei, etwas andieser Situation zu ändern, da deren Lösungsansätze dieAnforderungen der Anwender nur ungenügend erfüllen.Aus diesem Grund verfolgt dieser Beitrag drei wich-

tige Ziele: (𝐼) Es wird eine Definition von „Datenschutz“gegeben und daraus Schutzziele für ein Datensicherheits-system abgeleitet sowie Angriffsvektoren identifiziert.(𝐼𝐼) Mit dem Secured Data Container (SDC) wird ei-ne Erweiterung für die Privacy Management Platform(PMP) eingeführt, mit der alle Anforderungen an ein Da-tensicherheitssystem erfüllt werden. (𝐼𝐼𝐼) Abschließendwird gezeigt, dass die PMP mit dem SDC alle Anfor-derungen an ein Datensicherheitssystem erfüllt und auchhinsichtlich Performanz sehr gute Ergebnisse liefert. Ob-wohl der vorgestellte Prototyp der PMP und des SDCsfür Android umgesetzt wurden, lässt sich das zugrunde-liegende Konzept leicht auf andere Umgebungen, wie dieFacebook Platform, übertragen.

Danksagung Die PMP entstand initial in Zusammenarbeit mitGoogle München. Dafür möchten wir Google danken.

118 Christoph Stach, Bernhard Mitschang

Tabelle 2 Gegenüberstellung von Datensicherheitssystemen für Mobilplattformen anhand der Schutzziele aus Abschnitt 2.1

(a) (b) (c) (d) (e) (f) (g)AppGuard × × √ × √ × √

Aurasium √ √ √ × √ × √

CRêPE √ √ × × √ × √

Samsung KNOX √ √ √ × √ × ×Virtual Fort Knox √ √ √ √ √ √ ×

YAASE √ √ × × √ √ √

PMP × × √ √ √ × √

PMP & SDC √ √ √ √ √ √ √

Literatur

Arkin et al.(2005). Arkin B, et al. (2005) Software Penetration Tes-ting. IEEE Security & Privacy 3(1):84–87

Backes et al.(2013). Backes M, et al. (2013) AppGuard - EnforcingUser Requirements on Android Apps. In: TACAS ’13

Balebako et al.(2013). Balebako R, et al. (2013) "Little BrothersWatching You": Raising Awareness of Data Leaks on Smart-phones. In: SOUPS ’13

Chan et al.(2012). Chan PP, et al. (2012) DroidChecker: AnalyzingAndroid Applications for Capability Leak. In: WISEC ’12

Cherdantseva and Hilton(2013). Cherdantseva Y, Hilton J (2013)A Reference Model of Information Assurance & Security. In:ARES ’13

Conti et al.(2012). Conti M, et al. (2012) CRêPE: A System forEnforcing Fine-Grained Context-Related Policies on Android.IEEE Information Forensics and Security 7(5):1426–1438

Enck et al.(2014). Enck W, et al. (2014) TaintDroid: AnInformation-Flow Tracking System for Realtime Privacy Mo-nitoring on Smartphones. ACM Computer Systems 32(2):5:1–5:29

Felizardo et al.(2014). Felizardo V, et al. (2014) E-Health: CurrentStatus and Future Trends. In: Handbook of Research on Demo-cratic Strategies and Citizen-Centered E-Government Services,IGI Global, pp 302–326

Felt et al.(2012a). Felt AP, et al. (2012a) Android Permissions:User Attention, Comprehension, and Behavior. In: SOUPS ’12

Felt et al.(2012b). Felt AP, et al. (2012b) How to Ask for Permissi-on. In: HotSec ’12

Gaff et al.(2014). Gaff BM, et al. (2014) Privacy and Big Data.Computer 47(6):7–9

Geambasu et al.(2011). Geambasu R, et al. (2011) Keypad: AnAu-diting File System for Theft-prone Devices. In: EuroSys ’11

Gerber et al.(2015). Gerber P, et al. (2015) Usability Versus Priva-cy Instead of Usable Privacy. ACM SIGCAS Computers andSociety 45(1):16–21

Gorecky et al.(2014). Gorecky D, et al. (2014) Mensch-Maschine-Interaktion im Industrie 4.0-Zeitalter. In: Industrie 4.0 in Pro-duktion, Automatisierung und Logistik, Springer FachmedienWiesbaden, pp 525–542

Holtewert et al.(2013). Holtewert P, et al. (2013) Virtual Fort KnoxFederative, Secure and Cloud-based Platform for Manufactu-ring. Procedia CIRP 7:527–532

Jin et al.(2013). Jin H, et al. (2013) Recommendations-based Lo-cation Privacy Control. In: PerCom Workshops ’13

Kodeswaran et al.(2012). Kodeswaran P, et al. (2012) Securing En-terprise Data on Smartphones Using Run Time InformationFlow Control. In: MDM ’12

Larson et al.(2014). Larson J, et al. (2014) Spy Agencies ProbeAngry Birds and Other Apps for Personal Data. ProPublica

Leontiadis et al.(2012). Leontiadis I, et al. (2012) Don’t Kill MyAds!: Balancing Privacy in an Ad-supported Mobile Applica-tion Market. In: HotMobile ’12

Lookout(2014). Lookout (2014) 2014Mobile Thereat Report.Whi-te Paper, URL http://goo.gl/bnt10q

McGraw and Potter(2004). McGraw G, Potter B (2004) SoftwareSecurity Testing. IEEE Security & Privacy 2(5):81–85

Neisse et al.(2013). Neisse R, et al. (2013) A Trustworthy UsageControl Enforcement Framework. Intl J Mobile Computing andMultimedia Communications 5(3):34–49

Ongtang et al.(2012). Ongtang M, et al. (2012) Semantically RichApplication-Centric Security in Android. Security and Com-munication Networks 5(6):658–673

Posegga and Schreckling(2011). Posegga J, Schreckling D (2011)Next GenerationMobile Application Security. In: IT-Sicherheitzwischen Regulierung und Innovation, Vieweg+Teubner Ver-lag, pp 181–199

Reardon et al.(2012). Reardon J, et al. (2012) Data Node EncryptedFile System: Efficient Secure Deletion for Flash Memory. In:Security ’12

Russello et al.(2011). Russello G, et al. (2011) YAASE: Yet An-other Android Security Extension. In: PASSAT ’11

Samsung(2015). Samsung (2015) An Overview of the SamsungKNOX Platform. White Paper

Schmidt and Cohen(2013). Schmidt E, Cohen J (2013) The NewDigital Age: Reshaping the Future of People, Nations and Busi-ness. Alfred A. Knopf, Inc.

Shilton(2009). Shilton K (2009) Four Billion Little Brothers?: Pri-vacy, Mobile Phones, and Ubiquitous Data Collection. Com-munications of the ACM 52(11):48–53

Stach(2013a). Stach C (2013a) How to Assure Privacy on AndroidPhones and Devices? In: MDM ’13

Stach(2013b). Stach C (2013b) Wie funktioniert Datenschutz aufMobilplattformen? In: 43. GI-Jahrestagung

Stach(2015). Stach C (2015) How to Deal with Third Party Appsin a Privacy System—The PMP Gatekeeper. In: MDM ’15

Stach and Mitschang(2013). Stach C, Mitschang B (2013) PrivacyManagement forMobile Platforms—AReview of Concepts andApproaches. In: MDM ’13

Stach and Mitschang(2014). Stach C, Mitschang B (2014) Designand Implementation of the Privacy Management Platform. In:MDM ’14

Stahlberg et al.(2007). Stahlberg P, et al. (2007) Threats to Privacyin the Forensic Analysis of Database Systems. In: SIGMOD’07

Svajcer(2014). Svajcer V (2014) Sophos Mobile Security ThreatReport. Sophos, URL http://goo.gl/iIhj5e

Weiser(1999). WeiserM (1999) TheComputer for the 21st Century.ACM SIGMOBILE Mobile Computing and CommunicationsReview 3(3):3–11

Xu et al.(2012). Xu R, et al. (2012) Aurasium: Practical Policy En-forcement for Android Applications. In: Security ’12

http://goo.gl/bnt10qhttp://goo.gl/iIhj5e

1 Einleitung2 Datenschutz – rechtliche und technische Sicht3 Die Privacy Management Platform4 Der Secure Data Container5 Evaluation des SDCs6 Verwandte Arbeiten7 Zusammenfassung