Sicherheit in verteilten mobilen Anwendungen Masterarbeit Sicherheit in verteilten mobilen Anwendungen Vorgetragen von Anton Afanasjew

Inhalt Motivation und Ziele der Masterarbeit. Architektur, Entwurf und Realisierung eines Tracking-Dienstes. Sicherheit des Dienstes. Sicherheit der mobilen Kommunikation. Datenschutz. Status Quo.

1. Motivation und Ziele der Masterarbeit.

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.

Motivation: Ziele der Masterarbeit

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.

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.

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.

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.

2. Aufbau des Tracking-Dienstes.

Aufbau des Tracking-Dienstes: Architektur

Aufbau des Tracking-Dienstes: Tracking Service-Komponente

Aufbau des Tracking-Dienstes: Tracking Service-Komponente eStudy/eCollab-Modul. WebServices-Schnittstelle für mobile Clients. Dispatcher für Ajax-Requests. Realisiert in PHP.

Aufbau des Tracking-Dienstes: Tracking Service-Komponente WSDL Schnittstelle GetCertificate Login ReceivePosition ReceiveMessage MessageAcknowledgement CreateLandmark SendLandmarks DeleteLandmark Logout Kommunikation mit Mobilgeräten Clients

Aufbau des Tracking-Dienstes: Tracking Service-Komponente AjaxDispatcher Schnittstelle GetGroups GetPersons GetPersonData GetMessages AcknowledgeMessage SendMessage Kommunikation mit Webbrousern Clients

Aufbau des Tracking-Dienstes: ORM-Layer

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"]; }

Aufbau des Tracking-Dienstes: Ajax Client-Komponente

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.

Aufbau des Tracking-Dienstes: Ajax Client-Komponente 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 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: Mobile Client-Komponente

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.

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.

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.

3. Sicherheit des Dienstes.

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.

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.

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.

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.

4. Sicherheit der mobilen Kommunikation.

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

Sicherheit der Kommunikation: 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.

Sicherheit der Kommunikation: Kryptographiemodule J2ME BouncyCastle Lightweight-API Symmetrische/Asymmetrische Verschlüsselung Digitale Signaturen Alle wichtigen kryptographischen Algorithmen Keine Zertifikatsvalidierung PHP openssl

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.

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.

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.

5. Datenschutz.

Datenschutz Recht auf informationelle Selbstbestimmung: Recht des Einzelnen, grundsätzlich selbst über die Preisgabe und Verwendung seiner personenbezogenen Daten zu bestimmen.

Datenschutz: Ziele 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: 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.

6. Status Quo.

Status Quo Aktueller Zustand des Tracking-Dienstes: Real-Life Tests 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.

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.

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 GetGroupsAH 100,0 2 2,0 ORM-Records DoctrineUser 92,5 DoctrineCourse 81,3 GmAccess 90,9 3,0 GmPosition 95,7 4 4,0 GmMessage GmAuthorization GmAuthentication GmLandmark Utils JsonUtils 89,0 5,0 AuthTicket 46,6 6,0

Status Quo: Weiterentwicklungsvorschläge 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…

Danke für die Aufmerksamkeit!

Fragen und Demo