Masterarbeit Sicherheit in verteilten mobilen Anwendungen Vorgetragen von Anton Afanasjew

Masterarbeit

Sicherheit in verteilten mobilen Anwendungen

Vorgetragen von Anton Afanasjew

2

1. Motivation und Ziele der Masterarbeit.

2. Architektur, Entwurf und Realisierung eines Tracking-Dienstes.

3. Sicherheit des Dienstes.

4. Sicherheit der mobilen Kommunikation.

5. Datenschutz.

6. Status Quo.

Inhalt

3

1. Motivation und Ziele der Masterarbeit.

4

Motivation: Ziele der Masterarbeit

Sicherer Tracking-Dienst

Lokalisierung v. Personen mittels GPS und GoogleMaps.

Elemente aus Social Networks und standortbezogenen Diensten.

Sicherheit und Datenschutz.

Erweiterbarkeit und Anpassungsfähigkeit.

5

Motivation: Ziele der Masterarbeit

Außendienst-mitarbeiter

Außendienst-mitarbeiter

GPS-Signale

Auswertungsserver

Koordinaten über HTTPs

Koordinator

GoogleMap mit Positionen der

Mitarbeiter

GoogleMaps-Server

GoogleMaps-Dienst

6

Motivation: Tracking-Dienst als Teil einer Kollaborationsplattform

Das Pilotprojekt

Einführung und Evaluation einer Kollaborationsplattform.

Gefördert vom Hessischen Ministerium für Wissenschaft und Kunst.

Gemeinsam mit dem Hessischen Ministerium für Wirtschaft, Verkehr und Landesentwicklung.

Laufzeit 1. Mai 2008 bis 30. April 2009.

7

Motivation: Funktionale Anforderungen

Standortermittlung und –visualisierung über Mobiltelefone der Gruppenteilnehmer.

Koordination der mobilen Benutzer.

Asynchrone Kommunikation zwischen dem Koordinator und den mobilen Benutzern.

Erstellung und Verwaltung von Orientierungspunkten.

Anzeige der Entfernungen zwischen mobilen Benutzern.

8

Motivation: Nichtfunktionale Anforderungen

Sicherheit: Anwendung und Kommunikation müssen vor unerlaubten Zugriff geschützt werden.

Datenschutz: Benutzer müssen entscheiden können, wem sie ihre persönlichen Daten zur Ansicht stellen.

Portierbarkeit: Alle Komponenten des Dienstes müssen sich auf Spezifikationen, statt auf Hardware/Betriebssystemeigenschaften stützen.

Erweiterbarkeit: Durch Objektorientierung und lose Kopplung sollen die Komponenten leicht erweiterbar und austauschbar sein.

Testbarkeit: Die Geschäftslogik des Dienstes muss von automatisierbaren Unit-Tests abgesichert werden.

9

Motivation: Herausforderung

Anspruch Sicherheitskonzept für den Tracking-Dienst. Schutz des Dienstes. Schutz der mobilen Kommunikation. Datenschutz.

Problematik Sicherheit abhängig von der Plattform. Unausgereifte und fehlerhafte Security-Frameworks. Fehlende Unterstützung der Sicherheitsstandards. Eingeschränkte Ressourcen auf mobilen Geräten.

10

2. Aufbau des Tracking-Dienstes.

11

Aufbau des Tracking-Dienstes: Architektur

12

Aufbau des Tracking-Dienstes: Tracking Service-Komponente

13

Aufbau des Tracking-Dienstes: Tracking Service-Komponente

eStudy/eCollab-Modul.

WebServices-Schnittstelle für mobile Clients.

Dispatcher für Ajax-Requests.

Realisiert in PHP.

14

Aufbau des Tracking-Dienstes: Tracking Service-Komponente

WSDL Schnittstelle GetCertificate Login ReceivePosition ReceiveMessage MessageAcknowledgement CreateLandmark SendLandmarks DeleteLandmark Logout

Clients

Kommunikation mit Mobilgeräten

15

Aufbau des Tracking-Dienstes: Tracking Service-Komponente

AjaxDispatcher Schnittstelle GetGroups GetPersons GetPersonData GetMessages AcknowledgeMessage SendMessage

Clients

Kommunikation mit Webbrousern

16

Aufbau des Tracking-Dienstes: ORM-Layer

17

Aufbau des Tracking-Dienstes: ORM-Layer

Object Relational Mapping Doctrine 1.1 als ORM-Framework. Framework generiert Record-Klassen aus dem DB-Schema. Subklassen enthalten die Geschäftslogik. Datensätze als Objekte gekapselt. Zugriff auf die DB ausschließlich objektorientiert.

public static function createMessage($strTitle, $strText, $iAuthorId, $iMobile) {$objMessage = new GmMessage();$objMessage["title"] = $strTitle;$objMessage["text"] = $strText;$objMessage["author_id"] = $iAuthorId;$objMessage["mobile"] = $iMobile;$objMessage["time"] = time();$objMessage->save();return $objMessage["id"];

}

18

Aufbau des Tracking-Dienstes: Ajax Client-Komponente

19

Aufbau des Tracking-Dienstes: Ajax Client-Komponente

Webbrowserbasierter GUI.

Koordinierung der Gruppenteilnehmer.

Visualisierung von Standortdaten und Routen.

Ajax-Anwendung.

Besteht zu 100 % aus JavaScript und HTML.

Entwickelt mit Java 1.4 und Google Web Toolkit.

20

Google Webtool Kit

Entwicklung von Ajax-Clients mit Java.

Panels, Layouts, Listener, OOP usw.

Debuggen, Testen und Ausführen der Anwendung im Hosted Mode direkt aus Eclipse (JavaScript wird emuliert).

Übersetzung nach JavaScript.

Ergebnis ist browserunabhängig und performanter als die herkömmliche JavaScript-Entwicklung.

Erweiterbar mit Hilfe des Java Script Native Interface (JSNI).

Aufbau des Tracking-Dienstes: Ajax Client-Komponente

21

Entwurf ähnlich Java-Swing.

Benutzeraktionen stoßen ActionHandler an.

Diese führen AJAX-Requests aus.

An ActionHandler werden Listener registriert.

Gwt-GoogleMaps und Gwt-EXT APIs zeichnen Karte und GUI-Komponenten.

Aufbau des Tracking-Dienstes: Ajax Client-Komponente

22

Aufbau des Tracking-Dienstes: Mobile Client-Komponente

23

Aufbau des Tracking-Dienstes: Mobile Client-Komponente

Plattform: Java 2 Mciro Edition (J2ME).

Konfiguration: Connected Limited Device Configuration (CLDC1.1).

Profil: Mobile Information Device Profile (MIDP2.0).

Optionale Pakete: JSR-172 und JSR-179.

Container: Java Wireless Toolkit.

24

Aufbau des Tracking-Dienstes: Mobile Client-Komponente

J2ME - Schnittstellen:

lcdui-API: Grafische Oberfläche.

rms-API: Speicherung der Daten auf dem Gerät.

location-API: Ermittlung der Koordinaten.

webservice-API: Kommunikation mit dem Server.

Teilmenge der Mobile Service Architecture (MSA), die von den meisten relevanten Handyherstellern unterstützt wird.

25

Aufbau des Tracking-Dienstes: Mobile Client-Komponente

Anwendung besteht aus Formularen.

Jedem Formular können mehrere Kommandos zugeordnet werden.

Kommandos führen zu WebService-Requests und abhängig vom Ergebnis zu Formularübergängen und Zustandsänderungen der Anwendung (asynchron).

WebServiceRequest-Klassen werden aus der WSDL-Definition vom WTK generiert.

26

3. Sicherheit des Dienstes.

27

Sicherheit des Dienstes

Schadenszenarien: Funktionalität Datenbankinkonsistenz. Falsche Werte bei den Ausgaben. Verlust von Daten.

Schadenszenarien: Datenschutz Ansicht der Standorte von Gruppenteilnehmern durch

Unberechtigte. Unerlaubtes Aufzeichnen der Bewegungsprofile. Verlust der Vertraulichkeit von Nachrichten. Missverständnisse wegen falscher Nachrichten oder

Positionen.

28

Sicherheit des Dienstes:SQL-Injection Angriffsverfahren

Modifizierung der Datenbankabfragen durch SQL-Metazeichen in den Eingaben. SELECT * FROM User WHERE Username = ’$username’ AND Password = ’$password’ Eingabe Anton’ -- setzt die Passwortüberprüfung außer Kraft.

Schutzmöglichkeiten

Maskierung aller SQL-Metazeichen vor der Auswertung der Abfrage. Prepared Statements.

Umsetzung

ORM-Schicht mit dem Doctrine Framework. Zugriff auf Daten ausschließlich über Prepared Statements. Entwickler sehen DB-Datensätze als PHP-Objekte.

29

Sicherheit des Dienstes:Cross-Site Scripting Angriffsverfahren

Einschleusen von Skripten. z.B. ein JavaScript in ein Kommentar einbinden. Beim Lesen des Kommentars wird der Skript auf dem Webbrowser des betroffenen Benutzers

ausgeführt.

Schutzmöglichkeit

Maskierung aller HTML-Metazeichen vor der Generierung der Ausgabe. Verzicht auf HTML-Contents. Alternative Markup-Sprache.

Umsetzung

Klasse HtmlEncoding übernimmt die Maskierung bei der Ausgabegenerierung. HTML-Contents werden vermieden. Daten werden mit JSON strukturiert.

30

Sicherheit des Dienstes: Cross-Site Request Forgery Angriffsverfahren

Unterschieben eines Requests an einen angemeldeten Benutzer. Köder lockt zum Klicken des Hyperlinks oder zum Abschicken eines Formulars. Request löst eine Transaktion im Sinne des Angreifers aus.

Schutzmöglichkeit

Nur zustandmodifizierende Requests betroffen. Validierung der Hyperlink- bzw. Formularquellen nötig. Nur Requests aus vertrauenswürdigen Quellen werden akzeptiert.

Umsetzung

Klasse SecurityToken versieht die betroffenen Ajax-Requests mit zufälligen Werten (Tokens) und speichert ihre Kopien in der Session-Variable des Benutzers.

Empfangener Token wird vom Client zusammen mit dem nächsten Request verschickt. Der Token des Requests wird validiert. Requests mit unbekannten Tokens werden abgewiesen.

31

4. Sicherheit der mobilen Kommunikation.

32

Sicherheit der Kommunikation

Sicherheitsziele Authentifizierung

Server und Clients können einander ihre Identität beweisen.

Vertraulichkeit der SOAP-Nachrichten. Geheime Positionsdaten. Geheime Orientierungspunkte. Geheime Kurzmitteilungen.

Integrität Niemand kann die Position fälschen. Niemand kann die Kurzmittelungen manipulieren.

Kryptographische Maßnahmen Zertifikate Verschlüsselung Digitale Signaturen

33

Sicherheit der Kommunikation:Umsetzungsmöglichkeiten

Umsetzungsmöglichkeiten:

SSL/TLS Manchmal nicht ausreichend. Zusätzliche Absicherung notwendig.

WS-Security Spezifikationen Sinnvolle Möglichket, aber… Keine (oder keine ausreichende) Unterstützung seitens PHP-WS-Frameworks

PHP SOAP enthält die Spezifikation nicht. PHP WSF ist noch zu fehlerhaft.

Anwendungsebene Manuelle Implementierung notwendig. Kryptographiemodule/-pakete für PHP und J2ME notwendig.

34

Sicherheit der Kommunikation:Kryptographiemodule

J2ME

BouncyCastle Lightweight-API Symmetrische/Asymmetrische Verschlüsselung Digitale Signaturen Alle wichtigen kryptographischen Algorithmen Keine Zertifikatsvalidierung

PHP openssl

35

Sicherheit der Kommunikation:Authentifizierung

Der Server authentifiziert sich mit seinem Zertifikat. Client fragt nach dem Zertifikat. Server schickt das Zertifikat (bzw. die Zertifikatskette). Client erkennt das Root-Zertifikat oder fügt das

unbekannte Zertifikat zu den vertrauenswürdigen Zertifikaten in seinem Speicher hinzu.

Die Clients authentifizieren sich mit den Passwörtern aus den Tracking-Accounts in eCollab Username/Password beim Login. Dann Ticketaustausch mit dem Server.

36

Sicherheit der Kommunikation:Verschlüsselung

Initiale RSA-Verschlüsselung der Login-Daten:

Client verschlüsselt Daten mit dem öffentlichen Schlüssel aus dem Zertifikat.

Daten enthalten den vom Client generierten Sitzungsschlüssel. Server kann die Daten mit seinem privaten Schlüssel entschlüsseln

und den enthaltenen Sitzungsschlüssel speichern.

Dann AES-Verschlüsselung:

Gemeinsamer Sitzungsschlüssel wird verwendet. Symmetrische Verschlüsselung ist performanter.

37

Sicherheit der Kommunikation:Integritätsprüfung

Vor dem Versand der Nachricht wird ein Prüfwert gebildet.

digest := SHA1(plainmessage)

Prüfwert wird zusammen mit der Nachricht versandt.

Änderung der Nachricht führt zu einem anderen Prüfwert.

Der Angreifer kann den Prüfwert nicht anpassen, weil die Nachricht verschlüsselt übertragen wird.

38

5. Datenschutz.

39

Datenschutz

Recht auf informationelle Selbstbestimmung:

Recht des Einzelnen, grundsätzlich selbst über die Preisgabe und Verwendung seiner personenbezogenen

Daten zu bestimmen.

40

Der Benutzer entscheidet, wer seine standortbezogenen Daten ansehen darf.

Der Benutzer kann seine Lokalisierung jederzeit unmöglich machen.

Der Benutzer ist jederzeit über seine Lokalisierung

im Bilde.

Datenschutz: Ziele

41

Datenschutz: Maßnahmen Benutzer entscheidet, wer seine standortbezogenen Daten

ansehen darf: Explizite Berechtigung für die Lokalisierung notwendig. Sichtbarkeitsregeln. z.B.

Projektleiter im Projekt A. Projektleiter, Mitarbeiter und Sekretariat in den Projekten A, B. Mitarbeiter im Foyer.

Benutzer kann seine Lokalisierung jederzeit unmöglich machen: Kein Tracking, bevor ein Tracking-Account angelegt wurde. Account kann jederzeit gelöscht und wieder angelegt werden. Portalmitgliedschaft ohne Tracking-Account möglich.

Der Benutzer ist jederzeit über seine Lokalisierung im Bilde: Zustimmung der Policy beim Anmelden an den Tracking-Dienst. Nachricht auf dem Handybildschirm.

42

6. Status Quo.

43

Status Quo

Aktueller Zustand des Tracking-Dienstes: In die eCollab-Plattform integriert. Wird automatisch mit eCollab installiert. Bietet den Tracking-Client als Download an. Einsatzbereit.

Real-Life Tests Drei Testrechner und die eCollab-Testumgebung als Server. Unix und Windows-XP als Server-Betriebssysteme. Nokia E71, Sony Ericsson C905 sowie die MIDP2.0-

Referenzimplementierung als mobile Clients. Firefox, Chrome und Safari als Ajax-Clients. Drei Testpersonen bei Reisen und Spaziergängen getrackt.

44

Status Quo:Qualitätssicherung

Tests der Trackingdienst-Komponente: ca. 100 Unit-Tests mit rund 600 Zusicherungen. Vollständig automatisierte Testsuite für PhpUnit. Testdatenbank mit Preconditions.

Tests der mobilen Komponente: Automatisierte WS-Request-Tests. Können im Debug-Modus der Anwendung angestoßen werden.

Tests der Ajax-Komponente: Manuelle Tests.

Software-Metriken: Test-Coverage. Zyklomatische Komplexität. C.R.A.P.-Werte.

45

Status Quo: Metriken

Klasse Test-Coverage (%) C.C.N. (max) C.R.A.P. (max)

WebServices Schnittstelle

WebServicesImpl 85,6 5 5,6

ActionHandler

GetMessagesAH 61,7 13 182,0

GetPersonDataAH 79,2 7 7,4

GetPersonsAH 96,7 8 8,0

SendMessageAH 84,6 3 12,0

AcknowledgeMessageAH 85,1 3 12,0

GetGroupsAH 100,0 2 2,0

ORM-Records

DoctrineUser 92,5 2 2,0

DoctrineCourse 81,3 2 2,0

GmAccess 90,9 3 3,0

GmPosition 95,7 4 4,0

GmMessage 100,0 4 4,0

GmAuthorization 100,0 3 3,0

GmAuthentication 100,0 3 3,0

GmLandmark 100,0 2 2,0

Utils

JsonUtils 89,0 5 5,0

AuthTicket 46,6 2 6,0

46

Mobile Komponente: iPhone-Adaption des Clients. Multimedianachrichten mit Fotos und Dokumenten. Treffpunktkompass. Signal beim Betreten des Zielgebietes.

Serverkomponente: Bereitstellung von standortbezogenen Daten. Routenplaner. Wetterinformationen, Fahrpläne, Radaranzeigen…

Ajax-Komponente: Weitere Visualisierungen. Abdeckung von Regionen durch Personen. Filterung der Personen nach Ort.

Weiteres: Notenexport. eCollab-Funktionen wie Forum, News, Privatnachrichten…

Status Quo: Weiterentwicklungsvorschläge

47

Danke für die Aufmerksamkeit!

48

Fragen und Demo