Sicherheitsaspekte von Google Android

Aus Winfwiki

Fallstudienarbeit
Hochschule:	Hochschule für Oekonomie & Management
Standort:	Essen
Studiengang:	Bachelor Wirtschaftsinformatik
Veranstaltung:	Fallstudie / Wissenschaftliches Arbeiten
Betreuer:	Dipl-Inf._(FH)_Christian_Schäfer
Typ:	Fallstudienarbeit
Themengebiet:	Smartphone OS
Autor(en):	Pascal Obeid, Michael Kunz, Marcel Jelitto
Studienzeitmodell:	Abendstudium
Semesterbezeichnung:	SS11
Studiensemester:	2
Bearbeitungsstatus:	Bearbeitung abgeschlossen
Prüfungstermin:
Abgabetermin:

Inhaltsverzeichnis 1 Abkürzungsverzeichnis 2 Einleitung 3 Grundlagen IT Sicherheit 3.1 Bedrohungen für IT Systeme 3.2 Schutzbedarf 3.3 Schutzziele 3.4 Schutzmaßnahmen 3.5 Motivation der Angreifer 4 Android OS 4.1 Grundsätzliches 4.1.1 Geschichte und Allgemeines 4.1.2 Marktrelevanz 4.2 Architektur 4.2.1 Architektur Modell 4.2.1.1 Linux Kernel 4.2.1.2 Android Runtime 4.2.1.2.1 Dalvik Virtual Machine 4.2.1.2.2 Libraries 4.2.1.3 Application Framework 4.2.1.4 Applications 4.2.1.4.1 Activity 4.2.1.4.2 Service 4.2.1.4.3 Content Provider 4.2.1.4.4 Broadcast Receiver 4.2.1.4.5 Context Klasse 4.2.1.4.6 Sandbox 4.2.2 Dateisystem 4.2.3 Datenbanksystem 4.2.4 Komponenten – und Prozessmanagement 4.3 Sicherheitskonzept 4.3.1 Berechtigungskozept (Mandatory Access Control) 4.3.2 Zugriffsberechtigung auf Partitionsebene 4.3.3 Datenabstraktion 4.3.4 Applikationssignaturen 4.3.5 Linux Kernel Anpassungen 4.3.6 VPN 5 Einsatz von AndroidOS im Unternehmensumfeld 5.1 Generelle Anforderungen an Sicherheit in Unternehmen 5.1.1 Beschaffung / Einführung 5.1.2 Betrieb 5.1.3 Entsorgung 5.2 Argumente für AndroidOS 5.3 Nachteile von AndroidOS 6 Fußnoten 7 Literatur- und Quellenverzeichnis

1 Abkürzungsverzeichnis

Abkürzung	Bedeutung
IT	Informationstechnologie
OS	Operating System

2 Einleitung

Der Smartphonemarkt wächst immer weiter und gerade das Android-Betriebssystem hat in den letzten Jahren viele Marktanteile dazugewonnen^[1]. Dabei ist es nicht nur für Privatanwender ein interessantes Betriebssystem, sondern auch für den geschäftlichen Bereich. Doch gerade hier spielt die Sicherheit und das Risiko eine bedeutende Rolle. So bereitet ein Defekt oder ein Datenverlust dem Privatanwender meist keinen erheblichen Schaden, für den geschäftlichen Betrieb hingegen kann ein Dienstausfall oder der Verlust bzw. Diebstahl von Daten schwerwiegende Folgen haben. Die Folgen reichen von kurzzeitiger Einschränkung in der täglichen Arbeit bis hin zu hohen finanziellen Verlusten.
Diese Fallstudie beschäftigt sich mit der Definition möglicher Gefahren in der Informationstechnologie, den besonderen Anforderung an Sicherheit in Unternehmen, der Architektur und Funktionsweise von Google Android und wie das Betriebssystem diese Sicherheitsanforderungen zu erfüllen versucht. Abschließend erfolgt eine Nennenung der Vor- und Nachteile beim Einsatz von Android im Unternehmensumfeld.

3 Grundlagen IT Sicherheit

3.1 Bedrohungen für IT Systeme

Für IT Systeme gibt es eine Vielzahl verschiedenster Bedrohungen, wie z.B. ein Feuer oder ein technischer Defekt. Zur Früherkennung, Vermeidung oder Wiederherstellung müssen diese Bedrohungen zwar einzeln begutachtet werden, allerdings lassen sie sich zu bestimmten Bedrohungsgruppen zusammenfassen, gegen die man gleiche oder zumindest annähernd gleiche Maßnahmen ergreifen kann. Als prinzipielle Bedrohungen werden die auf unterschiedlichen Auslösern und Bedrohungen basierenden Auswirkungen bezeichnet und so kategorisiert^[2].

Dazu gehören:

• Ausfall oder Einschränkung von Ressourcen
  • (externe) Versorgungseinrichtungen, z.B. Strom, Gas, Wasser, Kommunikation (Ursache z.B. technische Defekte oder Beschädigungen bei Bauarbeiten)
  • Externe Dienstleister, z.B. Lieferanten, Software-Häuser, Service-Geber (Ursache z.B. Insolvenz oder Ausfall der Haustechnik)
  • Gebäude-, Raum-Infrastruktur und Hausrechnik (Ursache z.B. Explosions oder Überspannung)
  • ITK(Informationstechnologie und Telekommunikation)-Infrastruktur (Ursache z.B. Fehlbedienung oder Software-Fehler)
  • Personal (Ursache z.B. Lebensmittelvergiftung oder blockierte Anfahrt zur Arbeit)
• Blockade
  • Kommunikationsanbindung (Ursache z.B. Denial-of-Service-Attacken)
  • Gebäudezutritt (Ursache z.B. Streik oder Demonstration)
• Beschädigung oder Verlust, z.B. von Einrichtungsgegenständen, Computer-Equipment, Akten, Verträgen, Dokumenten, Dateien, Datenbeständen (Ursache z.B. Einbruch oder Vandalismus)
• Verfälschung, z.B. von Daten (Ursache z.B. Fehleingabe aufgrund von Tippfehlern oder Software-Fehler)
• Täuschung durch Vorspiegelung einer falschen Identität (z.B. Vortäuschung einer falschen Benutzeridentität oder Vortäuschung einer falschen IP(Internetprotokoll)-Absenderadresse)
• unzulässige Informationsgewinnung, z.B. über Betriebsgeheimnisse, geheime Forschungsergebnisse, Kundendaten, Lieferkonditionen (Ursache z.B. Abhören von Übertragungen oder Spionage)
• unzulässige Nutzung der Unternehmensinfrastruktur, z.B. von ITK-Systemen, Telefon oder Kopierer^[3]

Bedrohungen können nach Eintrittswahrscheinlichkeit kategorisiert werden. So bieten sie ein Indiz dafür, mit welcher Priorität Schutzmaßnahmen unter Erwägung des Kosten-Nutzen-Faktors ergriffen werden sollten. Dabei ist allerdings zu beachten, dass auch Bedrohungen mit geringer Eintrittswahrscheinlichkeit sehr kurzfristig eintreten und erheblichen Schaden anrichten können^[4].

3.2 Schutzbedarf

Ohne Priorisierung ist die Betrachtung und der Schutz von komplexen IT-Systemen nahezu unmöglich. Deshalb ist eine Ermittlung der besonders wertvollen Bestandteile eines IT-Systems sowie der existierenden Bedrohungen notwendig. So lassen sich Anstrengungen zur Sicherung sehr zielgenau ausrichten und verhältnismäßig schnell und wirksam abschließen. Das Ergebnis dieser Betrachtung wird als Schutzbedarf bezeichnet^[5].

Bei der Ermittlung des Schutzbedarfs werden zunächst die Anforderungen an das IT-System und alle dazugehörigen Bestandteile definiert. Diese können z.B. eine bestimmte Verfügbarkeit oder Performance sein. Gesammelt werden diese Anforderungen in einem Anforderungskatalog, der die Grundlage zur Bewertung und Gewichtung der Konsequenzen eventueller Verletzungen dieser Anforderungen bildet. Diese Konsequenzen werden dargestellt und nach Relevanz und Schwere bewertet und gewichtet. Aus dieser Bewertung erfolgt dann die Feststellung des tatsächlichen Schutzbedarfs^[6].

3.3 Schutzziele

Aus dem ermittelten Schutzbedarf werden Schutzziele abgeleitet. Sie beschreiben die Eigenschaften von Systemen, Komponenten und Applikationen, deren Erhaltung durch bestimmte Schutzmaßnahmen gewährleistet werden soll. Je konkreter und spezifischer Schutzziele definiert werden, desto einfacher ist es, passende technische Implementierungen zu finden oder zu errichten^[7].

Es gibt fünf Kategorien für Schutzziele:

• Integrität
• Verfügbarkeit
• Vertraulichkeit
• Authentizität
• Verbindlichkeit^[8]

Die Integrität beschreibt die Unveränderlichkeit. Dieses Schutzziel ist erfüllt, wenn das System zuverlässig nicht verändert wurde oder Änderungen voll erkenn- und nachvollziehbar durchgeführt wurden. Dazu sind Maßnahmen zur Verhinderung unerkannter Veränderungen notwendig. Die Integrität ist eine absolute Zielsetzung, Abstufungen sind nicht möglich^[9].

Die Verfügbarkeit bezieht sich auf Zugang und Zugriff auf Ressource, Systeme und Informationen. Diese gelten als verfügbar, wenn sie eingesehen und verändert werden können. Es werden also Maßnahmen benötigt, die Ereignisse vermeiden, die zu Beeinträchtigungen oder gar Unterbrechung der Verfügbarkeit führen. Die Verfügbarkeit ist eine relative Zielsetzung. Sie ist anteilig realisier- und messbar^[10].

Die Vertraulichkeit beschreibt die Exklusivität der Systeme und Informationen. Es muss sichergestellt werden, dass nur die dafür bestimmten Personen Zugriff auf und Zugang zu den entsprechenden Systemen und Daten haben. Die Vetraulichkeit ist ein absolutes Schutzziel^[11].

Die Authentizität beschreibt die Echtheit und Glaubwürdigkeit eines Objekts. Diese ist anhand einer eindeutigen Identität und charakteristischen Eigenschaften überprüfbar.^[12]

Die Verbindlichkeit beschreibt die Möglichkeit eine Menge von Aktionen eindeutig einem Subjekt zuzuordnen. Ist die Durchführbarkeit einer solchen Aktion im Nachhinein nicht abstreitbar, ist Verbindlichkeit gegeben^[13].

3.4 Schutzmaßnahmen

Grundsätzlich bestehen Schutzmaßnahmen in der IT aus den Komponenten:

• Konfiguration
• Überwachung
• Alarmierung
• Reaktion

Überwachung, Reaktion und Konfiguration basieren dabei auf bekannten Informationen^[14].

Die Konfiguration hat den Zweck die Grundlage für eine ordnungsgemäße Funktion der jeweiligen Komponenten (einzeln oder im Verbund) sicherzustellen. Die Abhängigkeit von der jeweiles eingesetzten Technologie macht eine Definition des Leistungsspektrums zwar sehr schwierig, aber grundsätzlich sollte die Konfiguration von zentraler Stelle erfolgen und die genutzten Mechanismen den Anforderungen der Schutzziele genügen^[15].

Die Überwachung dient dazu, definierte Normalzuständen zu kontrollieren und abweichende Zuständen zu erkennen. Dazu werden Informationen der zu überwachenden Systeme in bestimmten zeitlichen Abständen abgerufen und die erhaltenen Werte anhand festgelegter Kriterien bewertet. Wirksame Überwachung bildet den Grundstein für die weitere Behandlung von unerwarteten und unerwünschten Ereignissen^[16].

Die Alarmierung hat die Aufgabe das Auftreten bekannter zu behandelnder Ereignisse mit geeigneten Benachrichtigungen an einen bestimmten Empfängerkreis zu senden. Dieser Empfängerkreis beinhaltet Fachpersonal, das eine individuelle Begutachtung des Ereignisses durchführen kann. Dadurch kann ein Ereignis besser als Angriff bzw. als Verletzung der Sicherheitsrichtlinie eingestuft werden, als es nur durch automatische Qualifizierung möglich wäre^[17].

Die Hauptaufgabe der Reaktion ist die Behandlung erkannter und gemeldeter Ereignisse. Dazu gehören Maßnahmen zur Verhinderung von unerwünschten Systemzuständen oder zur Schadendbegrenzung beim Erreichen eines kritischen Zustands. Wichtig ist, dass eine Reaktion nur dann erfolgen kann, wenn vorher der Ereigniseintritt bekannt gemacht wurde, deshalb müssen Reaktionsmaßnahmen an die Überwachungs- und Alarmierungssysteme angeschlossen sein. Des Weiteren muss unbedingt auf die Angemessenheit der Reaktionsmaßnahmen geachtet werden, damit diese auch den richtigen Zweck erfüllen^[18].

3.5 Motivation der Angreifer

Im Wesentlichen wird bei Angriffen auf IT-Systeme zwischen fünf unterschiedlichen Motivationen unterschieden:

• Habgier: Angriffe werden durchgeführt, um einen persönlichen, materiellen Gewinn daraus zu erzielen
• Neugier: Angriffe werden durchgeführt, um die persönliche Neugier zu stillen
• Spionage: Angriffe werden durchgeführt, um gezielt in den Besitz bestimmter Informationen zu kommen
• Vergeltung: Angriffe werden durchgeführt, um gezielt und zur Befriedigung persönlicher Emotionen Schäden zu erzeugen
• Konspiration: Angriffe werden durchgeführt, um eventuelle Verfolger auf falsche Fährten zu locken^[19]

Bei der Habgier wird vorrangig darauf geachtet, dass der Angriff möglichst schnell durchgeführt wird und möglichst wenig, wenn möglich gar keine Spuren hinterlassen werden. Solche Angriffe lassen sich nur im Vorfeld wirklich wirksam verhindern, denn dazu ist es nötig den Angreifer vom Ziel fernhalten oder die Dauer bis zum Erreichen des Ziels so lang zu halten, dass eine Erkennung und Reaktion möglich ist. Dadurch wird der Angreifer von seinem Vorhaben abgebracht^[20].

Bei der Neugier handelt der Angreifer nur aus Lust am Wissen. Die eingesetzten Mittel variieren in Abhänigkeit von Kenntnissen und Ehrgeiz des Angreifers und er führt Angriffe fort, solange er unerkannt und ungestört bleibt. Meist finden die Angriffe allerdings ohne konkrete Planung und Vorbereitungszeit statt. Die angegriffenen Systeme werden in der Regel nicht bewusst beschädigt, allerdings kann es durch den Einsatz bestimmter Werkzeuge durchaus zu Schäden kommen. Die Informationen bleiben meist unbeschädigt, da der Angreifer nur lesend zugreift. Ein Angreifer, der aus Neugier handelt, lässt sowohl vorher, als auch während des Angriffs unterbrechen. Wichtig ist hierbei eine gut funktionierende Erkennung und Benachrichtigung^[21].

Bei der Spionage versucht der Angreifer bestimmte Informationen für einen Auftraggeber zu sammeln, auszuwerten und ggf. zu manipulieren. Dabei ist es für den Angreifer sehr wichtig unerkannt zu bleiben. Erfolgsfaktor sind dabei vor Allem die eingesetzten Mittel, denn sie beeinflussen die Dauer und Auffälligkeit des Angriffs. Auf eine sorgfältige Planung wird großen Wert gelegt, die Angriffe werden lange vorbereitet und es werden weit reichende Kenntnisse über das Opfer gesammelt. Meist verfügen die Angreifer über eine sehr gute Ausstattung. Für die Entdeckung solcher Angriffe können besonders Auswertungen von Logs oder Mitschnitten über einen längeren Zeitraum hilfreich sein^[22].

Angriffe aus Vergeltung verursachen den gravierendsten Schaden. Sie dienen der Befriedigung des Angreifers und werden oftmals als Reaktion auf vorhergehende Aktionen des Opfers gegen den Angreifer durchgeführt. Ihr Ziel ist möglichst großer Schaden, egal unter welchen Umständen, was dazu führt, dass der Angreifer weder bei der Vorbereitung, noch bei der Durchführung größere Sorgfalt walten lässt. Solche Angriffe sind deshalb schon alleine durch die erzeugten Schäden leicht zu erkennen. Bei Schutz und Abwehr kommt es hauptsächlich auf effektive und zeitnahe Erkennung und Benachrichtigung an^[23].

Bei der Konspiration versucht der Angreifer seine Identität zu verschleiern, indem er die Kontrolle über Rechner übernimmt, die er für weitere Angriffe auf andere Rechner nutzt. So wird es für Verfolger schwer, seine Spur zurückzuverfolgen. Möglich sind auch Kaskaden solcher Rechner. Wird ein Angriff erkannt, ist der Rechner, von dem dieser ausgeführt wurde, für den Angreifer nicht mehr nutzbar. Um die Kontrolle über solche Rechner zu erlangen, wird der Angreifer sehr vorsichtig vorgehen, da er nicht vorzeitig erkannt werden will. Effektive Maßnahmen zu ergreifen fällt deshalb schwer. Um solche Angriffe zu entdecken sind nur Mittel ähnlich wie denen bei der Spionage nützlich: Es müssen Log-Analysen über einen längeren Zeitraum durchgeführt werden und eine effektive Benachrichtigung ist wichtig. Die Unterscheidung zwischen böswilligen und unschuldigen Aktionen fällt bei solchen Angriffen schwer^[24].

4 Android OS

4.1 Grundsätzliches

Android ist eine auf Java basierte Software-Plattform, sowie ein Betriebssystem für mobile Endgeräte.

4.1.1 Geschichte und Allgemeines

Android wurde 2003 als Unternehmen von Andy Rubin gegründet. Im Jahre 2005 wurde dieses junge Unternehmen von Google gekauft. Ende 2007 gab Google bekannt gemeinsam mit der Open Handset Alliance* ein Mobiltelefon-Betriebssystem zu entwickeln, welches nach der einst gegründeten Firma Android benannt wurde. Am 21. Oktober machte Google das Betriebssystem offiziell verfügbar.

*Open Handset Alliance ist ein Zusammenschluss aus 80 Firmen unterschiedlicher Geschäftsbereiche, welcher für die Schaffung von offenen Standards für Mobilgeräte zuständig ist. Die Geschäftsbereiche aus welchen die Firmen kommen sind zum einen Netzbetreiber und Gerätehersteller als auch Softwarefirmen, Marketing Unternehmen und die Halbleiterindustrie. Unter anderem wirkt T-Mobile, ebay, Nvidia Corporation oder HTC mit in diesem Konsortium.

Alle Anwendungen für das Betriebssystem sind in Java geschrieben. Als Basis bringt das Betriebssystem schon die wichtigsten Anwendungen mit, wie z.B. einen E-Mail Client, Kalender, Webbrowser, Kartenmaterial, Kontakteverwaltung, SMS Programm sowie natürlich die Telefonfunktion. Die in Java geschriebenen Programme werden in Dalvik (.dex) konvertiert. Dalvik ist ein binäres Programmformat welches Anwendungen bei Ausführung in einer eigenen virtuellen Maschine startet. Dieses ermöglichen unter anderem eine sehr schnelle Ausführung sowie ein geringer Arbeitsspeicherbedarf. Die Anwendungen können (sofern vom Benutzer zugestimmt) auf alle Gerätefunktionen zugreifen, welches den Programmierern ermöglicht sehr innovative Programme zu entwickeln. Ein hoher Nutzwert kann entstehen, da verschiedenste Datenquellen verknüpft und mit Gerätefunktionen kombiniert werden können^[25][26].

4.1.2 Marktrelevanz

Das Android Betriebssystem verbreitet sich seit 2008 von Jahr zu Jahr stärker. Statistiken zeigen, dass Android voraussichtlich bis 2012 die Hälfte des Smartphone Markts abdeckt und somit, das durch Nokia entwickelte Symbian, von der Marktspitze verdrängen wird. Alleine in Deutschland wird der Marktanteil Androids innerhalb von einem Jahr von 1.7 % auf 35,5 % steigen. Grund für diese schnelle Verbreitung ist die immer größer werdende Anzahl von mobilen Endgeräten, welche mit Android ausgeliefert werden.

Eine weitere Übersicht zeigt die absoluten Marktanteile der verschiedenen Betriebssysteme:

Worldwide Mobile Communications Device Open OS Sales to End Users by OS (Thousands of Units)[27]
OS	2010	2011	2012	2015
Symbian	111,577	89,93	32,666	661
Market Share (%)	37.6	19.2	5.2	0.1
Android	67,225	179,873	310,088	539,318
Market Share (%)	28.7	38.5	49.2	48.8
Research In Motion	47,452	62,6	79,335	122,864
Market Share (%)	16.0	13.4	12.6	11.1
iOS	46,598	90,56	118,848	189,924
Market Share (%)	15.7	19.4	18.9	17.2
Microsoft	12,378	26,346	68,156	215,998
Market Share (%)	4.2	5.6	10.8	19.5
Other Operating Systems	11,417.4	18,392.3	21,383.7	36,133.9
Market Share (%)	3.8	3.9	3.4	3.3
Total Market	296,647	467,701	630,476	1,104,898

4.2 Architektur

Android ist ein Linux-Betriebssystem für Smartphones und basiert auf dem Linux Kernel 2.6x, der für die mobile Nutzung angepasst wurde und bei dem zahlreiche Bibliotheken komplett ersetzt wurden. Es ist eine Open-Source-Plattform, die von der Open Handset Alliance entwickelt wird, einem von Google initiierten breiten Zusammenschluss von Netzbetreibern, Smartphone-, Prozessor- und Chip-Herstellern sowie Softwarefirmen. Die für den Desktopeinsatz relevanten Erweiterungen fehlen für die Smartphone Version ( Beispielsweise das X-Window System). Android bietet die von Linux gewohnte Prozessverwaltung, so lässt sich jeder einzelne Prozess mit einem Prozess Manager anzeigen oder auch beenden. Das Betriebssystem ist optimiert für GPS und Bewegungssensoren, sowie für die Bedienung über einen Touchscreen. Ähnlich wie bei den Desktopversionen muss auch bei der Smartphone Version nicht mehr auf eine grafische Benutzeroberfläche verzichtet werden. Die von Google mitgelieferte Standard Benutzeroberfläche ist momentan jedoch nicht weit verbreitet am Markt, da die Smartphone-Hersteller meist auf eigene Benutzeroberflächen setzen^[28][29].

4.2.1 Architektur Modell

Android basiert auf einem Vier-Schichtenmodell

1. Dem Linux-Kernel mit den Hardwaretreibern
2. Der Android Runtime mit der Dalvik Virtual Machine (incl. Java Core Libraries sowie Standard-Bibliotheken)
3. Dem Application Framework
4. Den eigentlichen Anwendungen

4.2.1.1 Linux Kernel

Das Betriebssystem basiert auf dem Linux Kernel 2.6 und stellt somit dem übrigen Android Stack eine Hardwareabstraktionsschicht zur Verfügung. Folgende Funktionalitäten werden durch den Linux Kernel bereitgestellt:

• Speichermanagement
• Prozessmanagement
• Sicherheitsmodell
• Netzwerkschnittstelle

4.2.1.2 Android Runtime

4.2.1.2.1 Dalvik Virtual Machine

Die Dalvik Virtual Machine wurde von Google Mitarbeiter Dan Bornstein entwickelt, der sie nach einem Isländischem Dorf benannte, in dem seine Vorfahren lebten. Sie ist eine Java Virtual Machine(JVM), die an die Bedürfnisse für die mobile Nutzung angepasst wurde und basiert auf der Quelloffenen JVM Apache Harmony. Die DVM führt Code im Dalvik Executable-Format(.dex) aus, das so beschaffen ist, dass es möglichst wenig Arbeitsspeicher benötigt. Dies ist für die Nutzung auf mobilen Endgeräten mit geringen Ressourcen sehr wichtig. Es ist sehr einfach möglich, mit dem Tool dx Java-Bytecode in dex-Bytecode zu konvertieren. So ist es möglich Anwendungen für Android mit der Programmiersprache Java zu entwickeln. In der folgenden Abbildung sehen Sie den Weg des Javacodes von Entwicklung bis hin zur Ausführung auf einem mobilen Endgerät^[30].
^[31]

Des Weiteren nutzt die DVM die Register in Mikroprozessoren um trotz geringer Prozessorleistung ein schnelles System zu haben. Register sind Zwischenspeicher direkt im Mikroprozessor, die Berechnungen extrem schnell machen. Android nutzt mit der DVM also eine Register basierte JVM. Herrkömmliche JVMs sind dagegen Stack-basiert^[32].

Die Dalvik Virtual Machine bildet also den Kern der Android Runtime. Jede Anwendung, die über Android gestartet wird, läuft in einem eigenen Betriebssystemprozess und sogar in einer eigenen DVM. Dies ist nur möglich, da die DVM sehr klein und performant ist. Andernfalls würde die Nutzung einer eigenen Virtuellen Maschine pro Anwendung zu viele Ressourcen verbrauchen. Der Grund für die Nutzung einer eigenen DVM pro Anwendung ist höhere Sicherheit, sowie höhere Verfügbarkeit. Die Anwendungen teilen sich dadurch nämlich keinen gemeinsamen Speicher und ein Prozess ,der nicht mehr reagiert, ist für das Betriebssystem kein Problem, da es nur die entsprechende Anwendung betrifft^[33][34].

4.2.1.2.2 Libraries

Neben der DVM gehören auch die Core Libraries zur Android Runtime. Dies sind Pakete aus der Java Standard Edition , die Programmierern zur Verfügung stehen und das Entwickeln von Android Anwendungen somit erheblich erleichtern.

• Sprach und Unterstützungsbibliotheken
• Java.lang → elementare Java Grundtypen
• Java.util → Collections, Event-Handling, etc.
• Basisbibliotheken
• Java.io → Eingabe und Ausgabe von Dateien oder Streams
• Java.math → Rechenoperationen, Darstellung von Zahlen
• Etc.
• Integrationsbibliotheken
• Java.sql → Datenbankschnittstelle
• Sicherheitsbibliotheken
• Javax.crypto → Verschlüsselungstechnologien
• Java.security → Funktionalität des Java-Sicherheitsframeworks

Bibliotheken, die für die mobile Nutzung wenig Sinn ergeben, wie zum Beispiel „javax.print“ zum Drucken von Dokumenten, wurden nicht implementiert^[35][36].

4.2.1.3 Application Framework

Das Application Framework bildet den Unterbau für Android Anwendungen. Es enthält Android-spezifische Klassen und abstrahiert zu grunde liegende Hardware.

• Activity Manager
  Er regelt den Lebenszyklus der Applikationen
• Package Manager
  Er beinhaltet Informationen über alle Installierten Programme
• Window Manager
  Er Steuert die Anwendungsbezogenen Fenster^[37]

4.2.1.4 Applications

Android Anwendungen bestehen stets aus Komponenten. Das bedeutet, dass auf bereits vorhandene Komponenten zurückgegriffen werden kann, um so bereits vorhandene Funktionalitäten nutzen zu können. Selbst auf die Vorinstallierten Funktionen im Android Betriebssystem kann zurückgegriffen werden ,da der Code Open Source ist.

4.2.1.4.1 Activity

Activities werden benötigt um eine Oberfläche darzustellen, die es ermöglich mit dem Anwender zu interagieren. Activities werden bei der Dateneingabe, sowie der Darstellung von Daten benötigt. Mehrere Activities können zu einer komplexen Anwendung verknüpft werden.

4.2.1.4.2 Service

Services erledigen Hintergrundprozesse im System. Sie benötigen nicht unbedingt eine Benutzeroberfläche und werden weiter ausgeführt selbst wenn die Benutzeroberfläche geschlossen wird. Musik, die über die Benutzeroberfläche (also dem Musikplayer) gestartet wird, läuft auch dann weiter wenn der Player geschlossen wird um z.B. den Browser zu öffnen.

4.2.1.4.3 Content Provider

Die meisten Anwendungen haben die Möglichkeiten Daten zu speichern und zu laden. Der Content Provider ist ein Interface, das alle Datenmanagementoperationen ausführt. Dieses Interface kann auch mit anderen Applikationen geteilt werden.

4.2.1.4.4 Broadcast Receiver

Broadcast Receiver werden benötigt, damit Anwendungen mit dem System kommunizieren können. Eine Anwendung schickt also einen Broadcast, den der Receiver empfängt und an das System weitergibt. Broadcasts an das System können zum Beispiel die Benachrichtigung über niedrigen Akkustand oder störungen in der Netzwerkverbindung sein.

4.2.1.4.5 Context Klasse

Die Klasse Context ist eine Abstrakte Klasse, von der die Klassen Acitvity und Service abgeleitet sind. Sie bildet die Schnittstelle zur Android Runtime und ermöglicht so über bestimmte Methoden zum Beispiel das Starten eines Services oder das Schreiben einer Datei. Methoden der Klasse Context werden dann genutzt wenn man die Umgebung der Anwendung meint. Hierzu gehören:

• Das Dateisystem
• Der Classloader
• Die Berechtigungen der Anwendung
• Datenbanken
• Anwendungseigene Bibliotheken
• Bildschirmhintergrund
• Etc.

4.2.1.4.6 Sandbox

Android Anwendungen laufen in einem geschützten Speicherbereich, der so genannten Sandbox. Die Anwendungen können Daten im internen Verzeichnis „/data/data“ ablegen, in dem für jede Android Anwendung ein Verzeichnis angelegt wurde. Datenbanken der jeweiligen Anwendungen werden im Unterordner „Databases“ gespeichert und Dateien im Unterordner „files“. Die Sandbox steuert den Zugriff auf Ressourcen wie zum Beispiel Arbeitsspeicher, Speichermedien, Netzwerk etc. Die Berechtigungen werden expliziet pro Anwendung vergeben und ohne die entsprechenden Berechtigungen kann die Sandbox nicht verlassen werden^[38].

4.2.2 Dateisystem

Anrdroid verwendete ursprünglich das Dateisystem „Yet Another Flash File System“ (YAFFS), das seit Android 2.3 jedoch durch das standard Linux-Dateisystem Ext4 ersetzt wurde. Ext4 bietet im vergleich zu YAFFS einen Geschwindigkeitsvorteil bei Schreib – und Leseoperationen. Da allerdings einige Hardwarehersteller nicht auf das neue Dateisystem umstellen werden und andere wiederum ein eigenes Dateisystem verwenden gibt es hier keine Homogenität^[39].

4.2.3 Datenbanksystem

Als Datenbanksystem verwendet Android SQLite, da es quelloffen sowie klein und kompakt ist. Es ist für den Einsatz auf mobilen Endgeräten optimiert und verbraucht zur Laufzeit nur sehr wenig Speicher(ca. 175 bis 250kb). SQLite ist als Bibliothek in den Anwendungen verankert, somit können Anwendungen Datenbanken definieren und sie sofort verwenden ohne vorher einen Datenbankserver starten zu müssen. Die Datenbank wird als eine Datei mit der Endung „.db“ im Ordner „databases“ der jeweiligen Anwendung gespeichert. Es ist ebenfalls möglich, dass mehrere Anwendungen die selbe Datenbank nutzen^[40].

4.2.4 Komponenten – und Prozessmanagement

Android verzichtet komplett auf Swap Space, daher sind die Ressourcen im System knapp und das Komponenten – und Prozessmanagement muss reagieren sobald der Speicher knapp wird. Die vier Komponenten Activity, Service, Content Provider und Broadcast Receiver, die bereits erläutert wurden, bilden im Android System die Grundbausteine jeder Anwendung. Beim beenden einer Anwendung werden im Android Betriebssystem nicht automatisch auch die dazugehörigen Prozesse und die Dalvik Virtual Machine beendet. Dies wäre nämlich nicht zweckmäßig , da zum Beispiel die Kontakte Anwendung oder ihre Activities des öfteren genutzt werden und es nicht performant wäre jedes mal den Prozess und die virtuelle Maschine neu zu starten. Um festzustellen welche Prozesse bei Speichermangel beendet werden können, besitzt Android ein Regelwerk. Zuerst werden hierbei leere Prozesse, in denen keine Komponenten mehr laufen oder Prozesse, die lange nicht verwendet wurden beendet. Dies ist sehr wichtig, da sich der Heap einer DVM nie verkleinert und ein leerer Prozess somit auch sehr viel Speicherplatz belegen kann.
Die Abbildung zeigt den Lebenszyklus einer Android Activity^[41]:

4.3 Sicherheitskonzept

4.3.1 Berechtigungskozept (Mandatory Access Control)

Das Berechtigungskonzept von Android ist ein wichtiger Bestandteil vom Betriebssystem. So trägt der Nutzer im Vorfeld die Entscheidung ob er Anwendungen installieren will, welche entweder das gesamte System und / oder anderen Applikationen beeinflussen. Es wird eine Reihe von Brechtigungen durch Android vorgegeben wie z.B. der Zugriff auf z.B. das mobile Netzwerk oder andere Telefonfunktionen. Die Berechtigungen werden auf verschiedenen Ebenen der Plattform durchgeführt. Da Android auf Linux basiert werden die Berechtigungen mittels Benutzeridentität der Applikation sowie verschiedene Benutzergruppen (Linux GIDs) erteilt.

Es gibt verschiedene Risklevels (Normal, Dangerous, Signature und SystemOrSignature). Anwendungen mit dem Risklevel „Normal“ bekommen automatisch die benötigten Berechtigungen, welche aber jeder Zeit eingesehen werden können. Die unter „Dangerous“ deklarierten Anwendungen benötigen die Zustimmung im Vorfeld durch den User. Dies geschieht in Form von einer „Einverständnis-Abfrage“ vor der eigentlichen Installation der Applikation. Hier wird explizit darauf Hingewiesen, welche Berechtigungen benötigt werden um die Anwendung zu nutzen. Die Entwickler müssen also schon zum Entwicklungszeitpunkt diese „User-Permission“ deklarieren.

Meistens folgt das Genehmigungskonzept dem „Alles oder nichts“ Konzept. So wird meist vor der Installation eine Genehmigung in Form von Berechtigungsabfragen eingeholt, welche es der Anwendung erlaubt die benötigten Funktionen zu nutzen oder die Installation abzubrechen. Eingesehen können diese Berechtigungen jederzeit im Paketmanager des mobilen Endgerätes. Einzelne Bestandteile der Berechtigung können nicht entzogen bzw. deaktiviert werden. Es steht lediglich die komplette Deinstallation der Anwendung zur Verfügung. Mit „Signature“ deklarierte Anwendungen erhalten nur dann die Rechte, wenn sie mit demselben Zertifikat ausgestattet sind wie die Funktion auf welche sie zugreifen sollen. Das Risklevel „SystemOrSignature gilt für Anwendungen, welche mit einem System-Image ausgeliefert wurden oder das gleiche Zertifikat besitzen^[42].

4.3.2 Zugriffsberechtigung auf Partitionsebene

Der Systemaufbau der Android Plattform basiert auf dem Standard Linux Aufbau wurde aber zum Teil modifiziert um höchstmögliche Sicherheit vor Systemmodifikationen zu gewährleisten. Die /system-Partition ist nur lesend angelegt, da sich hier alle Programme sowie Systemdateien und Dienste befinden. Dieses verhindert das Überschreiben von Standardapplikationen wie z.B. Kontaktmanagement. Alle anderen Applikationsdaten werden unter /data/ abgelegt^[43].

4.3.3 Datenabstraktion

Jede Applikation besitzt ein für sich abgeschlossenes Heimatverzeichnis, in dem Daten abgelegt werden, welche nur von der Anwendung benötigt werden und auf welche nur diese Anwendung Lese- und Schreibberechtigungen erhält. Dies geschieht wie bei üblichen Linux Systemen auf Basis des Discretionary-Access-Control-Modells. Dieses Modell macht es möglich einzelnen Benutzern, Benutzergruppen oder „Allen“ bestimmte Berechtigungen wie Lese- Schreib oder Ausführungberechtigungen zu erteilen. So können Dateien anderer Applikationen nur dann gelesen bzw. geändert werden wenn diese für „Alle“ freigegeben ist. Hiermit kann also der Zugriff auf, für die Anwendung, „fremden“ Daten gesteuert werden^[44].

4.3.4 Applikationssignaturen

Die von den verschiedenen Entwicklern programmierten Anwendungen müssen mit einer identifizierbaren Signatur versehen werden. Sollte der Entwickler dieses nicht berücksichtigen bzw. vergessen wird diese Applikation nicht installiert, da der Paketmanager als Voraussetzung abfragt^[45].

4.3.5 Linux Kernel Anpassungen

Der Linux Kernel^[1] wurde für das Android System angepasst, so wurde zum Beispiel OpenBinder statt V-IPC als Interprozess-Kommunikationsframework^[2] verwendet. Dieses verhindert unter anderem einen Ressourcenverlust, welcher bei V-IPC entstehen kann durch die Verwendung von V-Semaphoren^[3]. Des Weiteren wird durch OpenBinder kontrolliert welche Prozesse Operationen auf anderen, entfernten Objekten durchführen dürfen. Somit wird auch ein Sicherheitsmodell auf IPC-Ebene gewährleistet.

^[1] Der Kern eines Betriebssystems, auf welchen alle weiteren Bestandteile beruhen. In diesem wird unter anderem der Zugriff auf die Hardware-Komponenten, Prozesse, Software und Netzwerkkomponenten festgelegt.
^[2] Ein Interprozess-Kommunikationsframework ist ein Programmiergerüst, welches für die Kommunikation zwischen Anwendungen eine einheitliche Struktur bietet.
^[3] V-Semaphoren sind mehrere Semaphoren^[4] mit welchen mehrere Operationen gleichzeitig durchgeführt werden können. Hiermit ist es möglich einen Semaphorensatz mit nur einer elementaren Semaphore anzufordern für welche wiederum verschiedene Funktionen definiert werden können^[46].
^[4] Semaphoren: Speicherbereich, dessen Wert von mehreren Prozessen ausgelesen und geändert werden kann^[47].

Die Einschränkungen auf die Netzwerkverwendung wurden ebenfalls im Kernel angepasst. So wurde der Kernel Code z.b so umgeschrieben, dass nun kontrolliert wird ob der anfordernde Prozess in der Benutzergruppe, welche für den Zugriff auf das Netzwerk angelegt wurde enthalten ist. Somit muss, um dies zu erreichen, der Applikation die Berechtigung „Internet“ zur Verfügung stehen.

4.3.6 VPN

Eine weitere Sicherheitsfunktion ist die Möglichkeit sich zu einem Virtual Private Network (VPN) zu verbinden. Hier kann zwischen der PTPP-Variante, welche mittels OpenVPN eingebunden ist oder der direkten Unterstützung von Virtual Private Network mittels IPSec gewählt werden^[48].

5 Einsatz von AndroidOS im Unternehmensumfeld

5.1 Generelle Anforderungen an Sicherheit in Unternehmen

Der Verein "Deutschland sicher im Netz e.V.", der seit 2007 unter der Schirmherrschaft des Bundesinnenministeriums steht und sich aus 15 Unternehmen, Verbänden sowie gemeinnützigen Organisationen zusammensetzt, bietet auf seinen Internetseiten aktuelle Informationen zum Thema Online-Sicherheit^[49].
Im Februar 2007 veröffentlichte der Verein eine Informationsbroschüre zum Thema Sicherheit von PDA und Smartphone im Unternehmensumfeld.

Durch die Vielzahl von Nutzungsmöglichkeiten von Smartphones und die immer stärkere Ersetzung von Notebooks im mobilen Bereich erhöht sich auch das Sicherheitsrisiko für Unternehmen. Vertrauliche Daten werden aus dem Unternehmensnetz kopiert und unterwegs bearbeitet. Die Geräte sind nicht automatisch in die IT-Struktur des Unternehmes eingebunden und profitieren deshalb nicht von einer sicheren und zentralen Authentisierung und Autorisierung. Sicherheitsmechanismen im Firmennetzwerk, wie z.B. Firewalls, greifen nicht mehr. Außerdem verwaltet das Gerät Zugriffsrechte selbst.
Die Mitarbeiter, die die Geräte nutzen, als auch das IT-Sicherheitsteam des Unternehmens müssen sich deshalb intensiv mit den Sicherheitsrisiken unter Betrachtung folgender Aspekte befassen:

• Beschaffung / Einführung
• Betrieb
• Entsorgung

Entsprechende Sicherheitsmaßnahmen müssen getroffen werden^[50].

5.1.1 Beschaffung / Einführung

Sicherheit muss schon bei der Beschaffung und Einführung geplant werden. Grundsätzlich bieten sich zwei Möglichkeiten:

• Bestimmte Gerätetypen kontrolliert einführen
• Privatgeräte für Einsatz im Unternehmen zulassen

Unabhängig davon welches Modell eingesetzt wird, ist zu beachten, dass Mitarbeiter ihr Smartphone viel stärker noch als den PC als persönliches Arbeitsmittel ansehen.Damit öffnen die Geräte eine empfindliche Sicherheitslücke in der IT-Infrastruktur des Unternehmens^[51].

Folgende Sicherheitsrichtlinien sind zu beachten:

• Sicherheitskatalog erstellen, der folgende Themen beleuchtet:
  • Sicherheitsmechanismen
  • Bedienkomfort
  • Schnittstellen
  • Hardware- und Software-Anforderungen
  • Zentrales Management
  • Authentifizierungsmöglichkeiten
  • Kosten
• Auf wenige Gerätetypen beschränken um Sicherheitsmechanismen zu vereinfachen
• Smartphones werden meist mit unzureichenden Sicherheitsmechanismen ausgeliefert. Ergänzende Sicherheitsanwendungen, die zur IT-Infrastruktur des Unternehmens kompatibel sind, sollten am Markt bezogen werden
• Verbindliche Richtlinien für die sichere Verwendung der Geräte definieren und implementieren
• Zentrale Administration für die Geräte einführen
• Leistungsfähigen Konfigurationsschutz aller mobilen Endgeräte gewährleisten
• Versicherungsschutz sollte Verlust und/oder Missbrauch der Geräte abdecken^[52]

5.1.2 Betrieb

1. Generelle Sicherheitsmaßnahmen
   • Nutzer regelmäßig für den sicheren Umgang mit Smartphones sensibilisieren
   • Wichtige Sicherheitsfunktionen wie Zugriffsschutz, automatische Sperre, Verschlüsselung, Internet Browser konfigurieren und verständlich für den Benutzer dokumentieren
   • Frühzeitig verbindliche Richtlinien zur sicheren Nutzung und Speicherung von Daten und Programmen etablieren
   • Mindestlänge von 8 Zeichen für Passworte verwenden und Groß- und Kleinschreibung sowie Sonderzeichen nutzen
   • Geräte über ein VPN in das Authentifizierungssystem des Unternehmens einbinden
   • Verschlüsselungsfunktion konfigurieren, bzw. nachinstallieren
   • Bestandsverzeichnis aller Geräte anlegen und Benutzer-ID, Gerätenummer, sowie Besonderheiten der Gerätekonfiguration dokumentieren
   • Betriebssystem und Sicherheitsanwendungen regelmäßig mit den neusten Updates aktualisieren^[53]
2. Geräteverlust und unautorisierter Zugriff auf das Gerät
   • Vorbeugende Maßnahmen:
   • Automatische Verschlüsselung aller Speichermedien des Geräts sicherstellen
   • Hinweis anbringen, an wen sich ein ehrlicher Finder wenden kann
   • Rückwirkende Maßnahmen:
   • Automatische Löschmechanismen, die notfalls bei Verlust aktiviert werden können, nutzen
   • Verlorene bzw. entwendete Geräte per Fernzugriff sperren^[54]
3. Datenverlust
   • Vorbeugende Maßnahmen:
   • Softwarelösungen bereitstellen, die dem Nutzer helfen regelmäßig Sicherheitskopien zu erstellen
   • Abgesicherte, möglichst verschlüsselte Synchronisationsmechanismen zwischen mobilen und stationären Geräten nutzen
   • Rückwirkende Maßnahmen:
   • Data-Recovery Leistungen des Geräteherstellers oder eines dafür spezialisierten Dienstleisters nutzen^[55]
4. Defekte Geräte
   • Vorbeugende Maßnahmen:
   • Siehe vorbeugende Maßnahmen unter Punkt 3
   • Rückwirkende Maßnahmen:
   • Vor dem Einschicken defekter Geräte beim Hersteller alle Daten sichern und löschen bzw. verschlüsseln^[56]
5. Missbrauch bei Datenübertragung und Angriff auf die Funkschnittstelle
   • Vorbeugende Maßnahmen:
   • Funkschnittstellen wie z.B. Bluetooth und Infrarot nur bei Bedarf aktivieren
   • Zugriffe auf das Unternehmesnetzwerk ausschließlich über VPN ermöglichen
   • Stets aktuelle Virensoftware und Firewall nutzen
   • Rückwirkende Maßnahmen:
   • Umgehend alle kompromittierten und bedrohten Passworte ändern
   • Umfassende Sicherheitsprüfung der attackierten Geräte durchführen^[57]
6. Unautorisierter Zugriff auf das Unternehmensnetzwerk
   • Vorbeugende Maßnahmen:
   • Informationen auf Datei– oder Verzeichnisebene verschlüsseln oder eine automatische Verschlüsselung des gesamten Speichermediums nutzen
   • Keine Passwörter oder andere Schlüssel im Klartext auf dem Speichermedium ablegen und die automatische Speicherung von Passwörtern grundsätzlich ausschalten
   • Weitere Schutzmechanismen wie Firewalls und Intrusion-Detection-Systeme nutzen
   • Rückwirkende Maßnahmen:
   • Siehe rückwirkende Maßnahmen unter Punkt 5^[58]

5.1.3 Entsorgung

Smartphones müssen, wie alle Datenträger, am Ende ihres Lebenszyklus geregelt entsorgt werden. Besondere Aufmerksamkeit gilt hierbei vor allem dem Umgang mit Speichermedien^[59].

1. Datenlöschung
   • Rücknahme der zu entsorgenden Geräte durch eine zentrale Annahmestelle organisieren und dort die Datenlöschungen durchführen
   • Spezielle Software um Daten unwiederbringlich zu löschen nutzen
   • Um Speicherkarten mechanisch zu zerstören z.B. einen Schredder nutzen
   • Als Alternative zur Zerstörung oder Löschung von Speichermedien bietet sich die vollständige Verschlüsselung aller Daten an^[60].
2. Entsorgung der Geräte
   • Geräte entweder beim Hersteller oder einem autorisierten Dienstleister entsorgen^[61]

5.2 Argumente für AndroidOS

Ein wesentlicher Vorteil des Android Betriebssystems ist sein offener Quelltext. Dieser ist speziell für Unternehmen insofern interessant, als das jede erdenkliche Änderung durchgeführt werden und das System so ganz auf die eigenen Bedürfnisse angepasst werden kann. Allerdings ist das mit erheblichem Aufwand verbunden, da der Quellcode zunächst studiert werden muss, um entsprechend Änderungen vornehmen zu können.

Aber auch ohne direkten Eingriff in den Quellcode bietet Android einige Schutzmechanismen und interessante Funktionen für Unternehmen. So ist es z.B. möglich ein Passwort zum Entsperren des Gerätes einzustellen. Dieses bietet dann Schutz vor ungewünschten Zugriff auf das Smartphone und damit auf die darauf gespeicherten Geschäftsdaten. Über ActiveSnyc ist eine zentrale Steuerung der Sicherheitsrichtlinien möglich, so dass Anwender gezwungen werden diese Passwortfunktion auch tatsächlich nutzen.

Des Weiteren ist über den Fernzugriff per ActivSync eine Datenlöschung möglich. Das heißt, im Falle eines Verlustes des Smartphones kann ein Administrator alle auf diesem Gerät gespeicherten Daten löschen und es in den Auslieferungszustand zurück versetzen. So kommt kein Dritter in den Besitz sensibler Geschäftsdaten, die sich womöglich auf dem Gerät befinden.

Über Softwareprodukte von Drittanbietern lassen sich außerdem weitere Sicherheitsrichtlinien installieren und das Smartphone kann per Fernwartung aktualisiert werden. So können Sicherheitslücken möglichst schnell und von zentraler Stelle aus geschlossen werden.

5.3 Nachteile von AndroidOS

Ein wesentlicher Nachteil von Android für Unternehmen dürfte die Snychronisation der Daten mit der Google-Cloud sein. Für die Nutzung von Android ist ein Google Account nötig und alle Kontakte werden generell mit diesem Account synchronisiert. Das bedeutet, dass das Unternehmen seine Daten nicht mehr ausschließlich selbst verwaltet. Man muss sich auf die Sicherheitsmechanismen von Google verlassen.

Ein weiteres Merkmal, das Sicherheitsbedenken verursachen könnte, ist die Möglichkeit SD-Karten zur Speicherplatzerweiterung nutzen zu können, wie es bei den meisten Android-Geräten der Fall ist. Der Anwender könnte wichtige Geschäftsdaten auf diesen SD-Karten speichern. Ein potentieller Angreifer kann diese Daten dann auch auslesen, wenn der nicht in der Lage ist das Gerät zu entsperren. Des Weiteren ist der Speicherplatz der Android Smartphones mit bis zu 64 GByte sehr groß. D.h. das mit unter sehr viele geschäftsbezogene Daten auf den Smartphones gespeichert werden, was für Angreifer um so interessanter ist. Schützen kann man sich dagegen nur mit einer Verschlüsselungssoftware von Drittanbietern, da Android so etwas standardmäßig nicht unterstützt.

Ein weiterer Nachteil ist, dass die standardmäßige Vorinstallation von Apps oder das Entfernen dieser über die Fernwartung nicht möglich ist. Das macht die Softwareverteilung und damit zu ergreifende Schutzmaßnahmen, wie das Installieren neuer Antiviren-Software oder Firewalls sehr umständlich.

Außerdem lässt sich die Bluetooth-Verbindung nicht zentral ausschalten. D.h. dass Hacker ggf. über diese Verbindung auf das Smartphone und damit auch auf das Firmennetzwerk zugreifen könnten. Auch hier sind also geeignete Sicherheitsmaßnahmen zu treffen, wie z.B. die Installation von Firewalls oder die Sensibilisierung der Anwender zu diesem Thema.

6 Fußnoten

1. ↑ o.V. (2011a), Weblink: http://www.heise.de/
2. ↑ Vgl. Müller (2008), S. 132
3. ↑ Vgl. Müller (2008), S. 132 ff.
4. ↑ Vgl. Müller (2008), S. 135
5. ↑ Vgl. Eschweiler, Psille (2006), S. 26 f.
6. ↑ Vgl. Eschweiler, Psille (2006), S. 27 f.
7. ↑ Vgl. Eschweiler, Psille (2006), S. 28
8. ↑ Vgl. Eschweiler, Psille (2006), S. 29
9. ↑ Vgl. Eschweiler, Psille (2006), S. 30
10. ↑ Vgl. Eschweiler, Psille (2006), S. 30
11. ↑ Vgl. Eschweiler, Psille (2006), S. 31
12. ↑ Vgl. Eckert (2009), Seite 6 f.
13. ↑ Vgl. Eckert (2009), S. 11
14. ↑ Vgl. Eschweiler, Psille (2006), S. 32 f.
15. ↑ Vgl. Eschweiler, Psille (2006), S. 33
16. ↑ Vgl. Eschweiler, Psille (2006), S. 33 f.
17. ↑ Vgl. Eschweiler, Psille (2006), S. 35 f.
18. ↑ Vgl. Eschweiler, Psille (2006), S. 39
19. ↑ Vgl. Eschweiler, Psille (2006), S. 49 f.
20. ↑ Vgl. Eschweiler, Psille (2006), S. 50 f.
21. ↑ Vgl. Eschweiler, Psille (2006), S. 51 f.
22. ↑ Vgl. Eschweiler, Psille (2006), S. 52 f.
23. ↑ Vgl. Eschweiler, Psille (2006), S. 53 f.
24. ↑ Vgl. Eschweiler, Psille (2006), S. 54 f.
25. ↑ Vgl. o.V. (2010), Weblink: http://www.operating-system.org
26. ↑ Vgl. o.V. (2008), Weblink: http://www.go-android.de/
27. ↑ Vgl. o.V. (2011), Weblink: http://www.gartner.com/
28. ↑ Vgl. o.V. (2011), Weblink: http://www.PCWELT.de
29. ↑ Vgl. o.V. (2011), Weblink: http://www.Heise.de
30. ↑ Vgl. o.V. (2011), Weblink: http://www.PCWELT.de
31. ↑ Vgl. Becker, Pant(2009) S. 17f.
32. ↑ Vgl. Mosemann, Kose (2009)
33. ↑ Vgl. o.V. (2011), Weblink: http://www.PCWELT.de
34. ↑ Vgl. Becker, Pant(2009) S. 17f.
35. ↑ Vgl. Mosemann, Kose (2009)
36. ↑ Vgl. o.V. (2011), Weblink: http://www.PCWELT.de
37. ↑ o.V. (2008), Weblink: http://www.OpenExpo.ch
38. ↑ Vgl. Becker, Pant(2009) S. 20f.
39. ↑ Vgl. o.V. (2011), Weblink: http://www.Heise.de
40. ↑ Vgl. o.V. (2011), Weblink: http://www.Heise.de
41. ↑ Vgl. o.V. (2011), Weblink: http://www.Heise.de
42. ↑ Vgl. o.V. (2011), Weblink: http://it-republik.de/
43. ↑ Vgl. o.V. (2011), Weblink: http://it-republik.de/
44. ↑ Vgl. o.V. (2011), Weblink: http://it-republik.de/
45. ↑ Vgl. o.V. (2011), Weblink: http://it-republik.de/
46. ↑ Vgl. Mauerer (2003), S. 226
47. ↑ Vgl. o.V. (2002), Weblink: http://su2.info/
48. ↑ Vgl. o.V. (2011), Weblink: http://it-republik.de/
49. ↑ Vgl. o.V. (2011), Weblink: http://www.sicher-im-netz.de
50. ↑ Vgl. Deutschland sicher im Netz (2007), S. 2
51. ↑ Vgl. Deutschland sicher im Netz (2007), S. 3
52. ↑ Vgl. Deutschland sicher im Netz (2007), S. 3
53. ↑ Vgl. Deutschland sicher im Netz (2007), S. 4
54. ↑ Vgl. Deutschland sicher im Netz (2007), S. 4
55. ↑ Vgl. Deutschland sicher im Netz (2007), S. 5
56. ↑ Vgl. Deutschland sicher im Netz (2007), S. 5
57. ↑ Vgl. Deutschland sicher im Netz (2007), S. 5
58. ↑ Vgl. Deutschland sicher im Netz (2007), S. 6
59. ↑ Vgl. Deutschland sicher im Netz (2007), S. 6
60. ↑ Vgl. Deutschland sicher im Netz (2007), S. 6
61. ↑ Vgl. Deutschland sicher im Netz (2007), S. 6

7 Literatur- und Quellenverzeichnis

Becker, Pant (2009)	Arno Becker, Markus Pant: Android Grundlagen und Programmierung, Ausgabe 1, Dpunkt.Verlag 2009
Deutschland sicher im Netz (2007)	Deutschland sicher im Netz e.V., Sicherheit von PDA und Smartphone - Informationsbroschüre für Entscheider, Erstellt von der Projektgruppe „Mobile Security“des Kompetenzbereiches Sicherheit, Februar 2007
Eckert (2009)	Eckert, Claudia: IT-Sicherheit: Konzepte – Verfahren – Protokolle, Ausgabe 6, Oldenbourd Wissenschaftsverlag 2009
Eschweiler, Psille (2006)	Eschweiler, Jörg; Psille, Daniel E.: Security@Work Pragmatische Konzeption und Implementierung von IT-Sicherheit mit Lösungsbeispielen auf Open-Source-Basis, Springer-Verlag, Berlin Heidelberg 2006
Mauerer (2003)	Mauerer, Wolgang: Linux Kernelarchitektur: Konzepte, Strukturen und Algorithmen von Kernel 2.6, Carl Hanser Fachbuchverlag, 2003
Mosemann, Kose (2009)	Heiko Mosemann, Matthias Kose: Android – Anwendungen für das Handy-Betriebssystem erfolgreich programmieren, Hanser Verlag 2009
Müller (2008)	Müller, Klaus-Rainer: IT-Sicherheit mit System, 3. Auflage, Friedr. Vieweg & Sohn Verlag, Wiesbaden 2008
o.V. (2002), Weblink: http://su2.info/	su2.info, Semaphoren, 2002, http://su2.info/uni/li/ipc_net_paper/node9.html, zuletzt aufgerufen am 28.05.2011 um 15:30
o.V. (2008), Weblink: http://www.go-android.de/	Go-Android, Was ist Android?, 2008, http://www.go-android.de/was-ist-android, zuletzt aufgerufen am 28.05.2011 um 14:00
o.V. (2008), Weblink: http://www.OpenExpo.ch	http://www.openexpo.ch/fileadmin/documents/2008Zuerich/Slides/33_Printemps.pdf, zuletzt aufgerufen am 28.05.2011 um 14:00
o.V. (2010), Weblink: http://www.operating-system.org	Operating-system.org, Android Betriebssystem, 2010, http://www.operating-system.org/betriebssystem/_german/bs-android.htm, zuletzt aufgerufen am 28.05.2011 um 14:00
o.V. (2011), Weblink: http://it-republik.de/	It-rebublik, Das Android-Sicherheitsmodell, 2011, http://it-republik.de/jaxenter/artikel/Das-Android-Sicherheitsmodell-3610.html, zuletzt aufgerufen am 28.05.2011 um 15:30
o.V. (2011), Weblink: http://www.gartner.com	Gartner, Android to Command Nearly Half of Worldwide Smartphone Operating System Market by Year-End 2012, 2011, http://www.gartner.com/it/page.jsp?id=1622614, zuletzt aufgerufen am 28.05.2011 um 14:15
o.V. (2011), Weblink: http://www.Heise.de	http://www.heise.de/mobil/artikel/Innenansichten-eines-Smartphone-Betriebssystems-1203743.html?artikelseite=8, zuletzt aufgerufen am 18.05.2011 um 13.00
o.V. (2011a), Weblink: http://www.Heise.de	http://www.heise.de/newsticker/meldung/Smartphones-Android-ueberholt-Symbian-Apple-verliert-Marktanteile-1180547.html, zuletzt aufgerufen am 18.05.2011 um 13.00
o.V. (2011), Weblink: http://www.PCWELT.de	http://www.pcwelt.de/ratgeber/Android-Runtime-und-Dalvik-Virtual-Machine-Smartphone-Grundlagen-1005304.html, zuletzt aufgerufen am 18.05.2011 um 13.00
o.V. (2011), Weblink: http://www.sicher-im-netz.de	Deutschland sicher im Netz e.V., Wir über uns, 2011, https://www.sicher-im-netz.de/wir_ueber_uns/wir_ueber_uns.aspx, zuletzt aufgerufen am 18.05.2011 um 13.00