Internet Datasafe Sicherheitstechnische Herausforderungen

Transkript

1 ERFA-Tagung Internet Datasafe Sicherheitstechnische Herausforderungen Prof. Dr. Marc Rennhard Institut für angewandte Informationstechnologie InIT ZHAW Zürcher Hochschule für Angewandte Wissenschaften Marc Rennhard, , ERFA_Datasafe.pptx 1

2 Herausforderungen und Rolle des InIT Eine wichtige Aufgabe des InIT lag im Bereich der Sicherheit, wo es z.b. um folgende Fragestellungen ging: Benutzerauthentisierung mit Passwörtern aber geht das besser als was man üblicherweise verwendet? Datensicherheit: kryptographische Algorithmen und Schlüsselmgmt wie wird was verschlüsselt (Sicherheit vs. Performance vs. Usability) Sicherer und zuverlässiger Vererbungsprozess Benutzerfreundliche Two-Factor Authentisierung mit dem Mobiltelefon Sicherer SWE-Prozess (Security Architecture, Security Requirements, sichere Implementierung kritischer Funktionen...) Security Testing (Fokus auf Penetration Testing) Marc Rennhard, , ERFA_Datasafe.pptx 2

3 Grundsätzliches zur Architektur DataInherit ist eine Webapplikation Serverseitige Technologie: Java Clientseitige Technologie: Adobe Flash/Flex Zusätzlich: iphone App für den Zugriff auf den Password-Store Benutzer benötigt irgendeinen Browser mit Flash-Unterstützung ~97% der Benutzercomputer erfüllen dies Schutz des Kommunikationskanals mit SSL/TLS ( Dies schützt die Daten auf dem Übertragungsweg, nicht aber auf dem Server Marc Rennhard, , ERFA_Datasafe.pptx 3

4 Sicherheit der Daten (1) Früh im Projekt wurden gewisse Designentscheide gefällt: Auf dem Server sind die Daten wenn immer möglich nur in verschlüsselter Form abgelegt Dies kann man erreichen, indem Daten im Client (Browser) verschlüsselt und auch wieder entschlüsselt werden Damit sieht der Server die Daten überhaupt nie im Klartext Problem: Performance bei grossen Daten Kompromiss: Daten werden serverseitig verschlüsselt Der Server kann die Daten aber nur entschlüsseln, wenn der Benutzer angemeldet ist Daten sind nur innerhalb der Applikation (im Memory) im Klartext vorhanden, auf der Disk aber immer nur verschlüsselt Marc Rennhard, , ERFA_Datasafe.pptx 4

5 Sicherheit der Daten (2) Ausnahme: Passwörter werden zusätzlich Ende-zu-Ende verschlüsselt Durch die geringe Datenmenge ist dies problemlos möglich Was bringt dies, wenn wir doch bereits mit SSL/TLS eine gute Kommunikationssicherheit erreichen? SSL/TLS hat Risiken beim Zertifikatsmanagement, was ein Mitlesen der Daten durch einen Man-in-the-Middle ermöglichen kann Es gibt Firmen, die ausgehende SSL-splitting Proxies einsetzen, um auf den Klartext von Daten zuzugreifen Fazit bezüglich Sicherheit der Daten: Vernünftiger Kompromiss zwischen Sicherheit, Performance und Usability Marc Rennhard, , ERFA_Datasafe.pptx 5

6 Benutzerauthentisierung Es führt (noch) nichts an Passwörtern vorbei obwohl die damit verbundenen Probleme bekannt sind: Es ist sehr einfach, ein schlechtes Passwort zu wählen Bei sehr schwachen Passwörtern sind Online-Attacken möglich Bei relativ schwachen Passwörtern sind Offline-Attacken möglich (z.b. durch Kompromittierung des Servers) Durch brechen der SSL/TLS-Sicherheit ist das Passwort im Klartext für den Angreifer ersichtlich Unser Ziel war es, ein Passwort-basiertes Verfahren zu verwenden, gleichzeitig aber die obigen Limiten in den Griff zu kriegen Durch die Verwendung einen speziellen Protokolls: SRP Mittels Feedback an den Benutzer, damit er ein genügend gutes Passwort wählt Marc Rennhard, , ERFA_Datasafe.pptx 6

7 Typischer Einsatz von Passwörtern heute (1) Wie werden Passwörter heute typischerweise verwendet: Über einen unsicheren Kanal: Server sendet einen zufälligen Wert (Challenge) Benutzer nimmt diesen Wert und berechnet daraus eine Response, indem er z.b. die Challenge mit dem Passwort verschlüsselt Die Response wird zum Server gesendet, welcher prüft, ob die richtige Response berechnet wurde Problem: Angreifer kann Challenge und Response mitlesen und wahrscheinliche Passwörter durchprobieren, bis eines passt Über einen sicheren Kanal (meist SSL/TLS): Benutzer sendet einfach Benutzername und Passwort über den geschützten Kanal Oder zusätzlich geschützt durch ein Challenge-Response Verfahren Problem: SSL/TLS kann angegriffen werden, wodurch der Angreifer direkt oder durch Ausprobieren an das Passwort gelangt Marc Rennhard, , ERFA_Datasafe.pptx 7

8 Typischer Einsatz von Passwörtern heute (2) Grundproblem dieser Verfahren: Passwörter werden in einer Plaintext-äquivalenten Form übertragen (oder auch serverseitig abgespeichert) Dies bedeutet, dass der übertragene / abgespeicherte Wert und das Passwort einen direkten Zusammenhang haben z.b. durch einen Hash oder eine einfache Verschlüsselung Wenn man diesen Zusammenhang eliminiert, so hat man das Problem der Offline-Attacken ebenfalls eliminiert Es gibt tatsächlich ein Protokoll, das dies weitgehend erreicht: das Secure Remote Password (SRP) Protokoll Entwickelt an der Standford University, RFC 2945 Marc Rennhard, , ERFA_Datasafe.pptx 8

9 Secure Remote Password (SRP) Protokoll Das Protokoll hat im Vergleich zu den üblich eingesetzten Verfahren diverse Vorteile: Der mathematische Zusammenhang zwischen dem Passwort und den übertragenen Daten ist sehr viel komplexer Offline-Attacken werden dadurch ebenfalls sehr viel komplexer, sowohl durch Mitlesen der Daten als auch durch Kompromittieren des Servers SRP ist zusätzlich ein Key-Exchange Verfahren, d.h. bei jedem Authentisierungsvorgang wird ein starkes Shared Secret generiert dieses wird für die Ende-zu-Ende Verschlüsselung verwendet Wenn das so toll ist, wieso wird es nicht viel häufiger eingesetzt? Es müssen 6 Nachrichten ausgetauscht werden (einfache Passwort- Verfahren benötigen nur 1 oder 2 Nachrichten) Die Berechnungen (Client und Server) sind viel aufwändiger (Public-Key Berechnungen) Grundsätzlich lässt sich SRP heute aber problemlos und benutzerfreundlich implementieren auch auf Small Devices Marc Rennhard, , ERFA_Datasafe.pptx 9

10 Erreichen einer gewissen Passwortstärke Gegen ganz schwache Passwörter nützt natürlich auch SRP nicht viel Insbesondere weil dann die Online-Attacke möglich wird DataInherit bietet dem Benutzer deshalb eine Hilfestellung bei der Wahl des Passworts Angabe der Passwortstärke bei der Eingabe eines Passwortes Stärke wird berechnet durch ein Punktesystem (Länge, Zeichenmix...) Gleichzeitig wird geprüft, ob das Passwort nicht einem Wort in einem Dictionary entspricht Marc Rennhard, , ERFA_Datasafe.pptx 10

11 Ein Passwort für alles (1) Aus Gründen der Usability soll der Benutzer genau ein Passwort haben Wird sowohl für die Authentisierung als auch für den Schutz seiner Daten auf dem Server verwendet Das Passwort hat im Allgemeinen aber eine viel geringere Stärke als ein richtiger kryptographischer Schlüssel (z.b. 128 Bits) Die ganze kryptographische Sicherheit der Dokumente eines Benutzers basiert auf seinem Master Key Dieser wird vom Server nach der Registrierung generiert Er wird serverseitig mit einem vom Passwort des Benutzers abgeleiteten Schlüssel (User Key) verschlüsselt abgespeichert Der Master Key wird nur während einer aktiven Benutzersession entschlüsselt Marc Rennhard, , ERFA_Datasafe.pptx 11

12 Ein Passwort für alles (2) Wie generiert man einen Schlüssel aus einem Passwort? Mit einer Password-Based Key Derivation Function Wir verwenden hier PBKDF2 (RFC 2898) Die Komplexität von PBKDF2 kann parametrisiert werden, um den Aufwand für einen Angreifer zu erhöhen Nach der Anmeldung erhält der Server vom Client den User Key, mit welchem der Server den Master Key entschlüsseln kann Damit hat der Server den für die Session notwendigen Schlüssel Diese Kommunikation ist mit dem SRP Shared Secret geschützt Marc Rennhard, , ERFA_Datasafe.pptx 12

13 Schlüsselmanagement Marc Rennhard, , ERFA_Datasafe.pptx 13

14 Two-Factor Authentisierung Ein DataInherit-Benutzer kann optional Two-Factor Authentisierung verwenden Dabei gelangt erhält der Benutzer einen One-Time Login-Code per SMS auf sein Handy gesendet (ähnlich mtan-verfahren) Problem: das Verfahren ist nicht gut geeignet, wenn die Applikation selbst auf einem Mobiltelefon verwendet wird (iphone App) Usability bzw. technische Gründe (nicht beim iphone) beim Umschalten zwischen Applikation und Lesen einer SMS Nachricht Lösung: Entwicklung von DoubleSec als Alternative Marc Rennhard, , ERFA_Datasafe.pptx 14

15 DoubleSec (1) Worauf basiert die Sicherheit von mtan? Ohne Besitz des Handys mit der Zielnummer ist es für den Angreifer schwierig, an den Inhalt der SMS Nachricht zu gelangen Die Sicherheit basiert also auf der Annahme, dass das Handy als physical Security-Token dient DoubleSec erreicht dasselbe, aber transparent für den Benutzer Annahme: ein Shared Secret (S n-1 ) zwischen Handy und Server beidseitig sicher gespeichert Bei Aufbau (Login) einer neuen Session wird aus dem Passwort und S n-1 ein neues Shared Secret S n berechnet Das Handy sendet S n an den Server, wo es verifiziert wird S n wird zudem beidseitig für das nächste Login gespeichert Bootstrapping: Beim ersten Login (für S 0 ) wird ein SMS-Code verwendet Marc Rennhard, , ERFA_Datasafe.pptx 15

16 DoubleSec (2) In unserem Fall verwenden wir das SRP Shared Secret, um S n zu berechnen Ebenfalls wird S n mit diesem Shared Secret verschlüsselt übertragen Wieso ist dies ähnlich sicher wie mtan? Ohne Besitz des Handys kennt der Angreifer S n-1 nicht und kann damit S n nicht berechnen Theoretisch könnte Malware auf dem Handy S n-1 auslesen, dies ist bei mtan aber genau so Marc Rennhard, , ERFA_Datasafe.pptx 16

17 Sichere Vererbung (1) Der Vererbungsprozess von DataInherit muss sicher und zuverlässig sein: Ein erbberechtigter Benutzer darf die Daten nicht einsehen, bevor der Erblasser dies zulässt Andererseits muss der berechtigte Zugriff auf die Daten möglich sein Wie erhält eine erbberechtigte Person Zugriff auf die Daten? Die DataInherit-Betreiber haben keinen Zugriff auf die Daten Das Passwort des Erblassers muss als verloren betrachtet werden Der Erblasser erzeugt in DataInherit für die Erbberechtigten ein Dokument mit einer Anleitung und einem Activation Code Das Dokument wird an die Erbberechtigten verteilt Mit diesem Code kann ebenfalls der Master Key freigeschaltet werden, womit (kryptographisch) der Zugriff auf die Daten möglich wird Der Erblasser kann die Erbberechtigung jederzeit widerrufen Marc Rennhard, , ERFA_Datasafe.pptx 17

18 Sichere Vererbung (2) Um den Vererbungsprozess zu starten, gibt ein Erbberechtigter den Activation Code ein Nun beginnt ein Prüfprozess um mit hoher Wahrscheinlichkeit sicherzustellen, dass ein frühzeitiger Erbbezug nicht möglich ist Ein DataInherit Benutzer kann dazu eine Wartezeit spezifizieren, z.b. 30 Tage, während der folgendes passiert: DataInherit versucht, den Benutzer auf von ihm spezifizierten Kommunikationskanälen zu erreichen z.b. , SMS (auch je mehrere) Die Wahrscheinlichkeit, dass der (lebende) Benutzer all diese Informationen verpasst, ist minimal Während dieser Zeit kann sich der Benutzer jederzeit einloggen und den Vererbungsprozess stoppen Nach der Wartezeit erzeugt DataInherit einen Account für den Erbberechtigten und kopiert die ihm zugewiesenen Daten Marc Rennhard, , ERFA_Datasafe.pptx 18