Whitepaper. ginlo & Sicherheit

Transkript

1 Whitepaper ginlo & Sicherheit 1 September 2017

2 Inhaltsverzeichnis Bestätigung der Handynummer... 3 Account-Passwort... 3 Tokens... 4 Zurücksetzen des Account-Passworts... 4 Zugangscode... 5 Lokale Verschlüsselung... 5 Ende-zu-Ende-Verschlüsselung... 6 Schlüsselerzeugung... 6 Schlüssel-Backup... 6 Verschlüsselung von ginlo Nachrichten (Instant Messages)... 6 Verschlüsselung von als ginlo Nachrichten gesendeten Dateien (Instant Messages) s und Webchat... 7 Transportverschlüsselung... 7 Seite 2 von 8

3 Über dieses Dokument In diesem Whitepaper erfahren Sie, welche Verschlüsselungskonzepte, Authentifizierungsmethoden und andere Maßnahmen die Brabbler AG (als der Betreiber von ginlo) zum Schutz der Daten ihrer Nutzer einsetzt. Weitere Infos dazu, welche Daten wir speichern und warum, finden Sie im Whitepaper ginlo & Datenschutz. Registrierung eines Benutzer-Accounts Bestätigung der Handynummer Für die Registrierung eines Benutzer-Accounts ist eine gültige Handynummer erforderlich. Um die Registrierung abzuschließen, muss diese Nummer innerhalb von 7 Tagen bestätigt werden. Der Client hat 3 Versuche, um den richtigen Bestätigungscode an den Server zu schicken. Nach 3 fehlgeschlagenen Versuchen muss sich der Nutzer noch einmal neu registrieren. Zur Verifizierung der Handynummer wird vom Server eine SMS mit einem Zufalls-Bestätigungscode c R [10 5, ] an den ginlo Client geschickt. Bei Bedarf kann sich der Nutzer die SMS erneut zuschicken lassen. Hier greift eine Zeitverzögerung von 2 Minuten zwischen den jeweiligen Anfragen. Abbildung 1 - Registrierung eines Benutzer-Accounts Account-Passwort Nutzer müssen zum Schutz Ihres Accounts ein Passwort vergeben. Auf dem ginlo Client wird das Passwort nicht gespeichert. Der Server speichert den Hashwert des Passworts. Dieser wird wie folgt erstellt: Ein SHA-512-Hash [1] wird erzeugt und mithilfe der bcrypt-hashfunktion [2] mit einer Stärke von 11 und einem eigenen Salt pro Nutzer neu gehasht. Dieser mittels bcrypt generierte Hash wird mithilfe von AES-256 [3] im GCM-Modus [4] verschlüsselt. Dazu wird pro Passwort ein separater Schlüssel verwendet. Seite 3 von 8

4 Authentifizierung Tokens Die Authentifizierung basiert auf dem OAuth2-Protokoll [5] unter Verwendung von JSON Web Tokens (JWT) und Refresh Tokens [6]. Bei der erstmaligen Anmeldung wird jeweils ein solcher Token erzeugt. Der Access Token wird für die Authentifizierung von API-Anfragen verwendet und ist 10 Minuten gültig. Der Access Token ist an das Gerät gebunden, auf dem sich der Nutzer angemeldet hat. Zusammen mit dem Access Token wird die verschlüsselte IP-Adresse gespeichert, um Missbrauch (z. B. gleichzeitigen Zugriff auf denselben Account von verschiedenen Kontinenten aus) festzustellen. Wenn der Access Token abgelaufen ist, generiert der Client mithilfe des Refresh Tokens ein neuen Access Token [7]. Der Refresh Token ist 30 Tage gültig. Greift ein Nutzer also länger als 30 Tage nicht auf den Client zu, so muss er sich erneut mit seinem Benutzernamen und Account-Passwort anmelden. Erst dann erhält der Client ein neues Token-Paar. Jeder ginlo Benutzer- Account besitzt maximal 30 Refresh Tokens, d. h., dass ein Nutzer sich auf bis zu 30 Geräten gleichzeitig anmelden kann. Abbildung 2 - Token Refresh Zurücksetzen des Account-Passworts Nutzer können ihr Account-Passwort wie folgt zurücksetzen: Der Nutzer gibt seine registrierte Handynummer an. Danach wird er zu einem Webformular weitergeleitet und kann dort ein neues Account-Passwort vergeben. Zum Abschicken des Formulars muss der Nutzer seine Identität durch Eingabe einer einmaligen PIN bestätigen, die an seine Handynummer geschickt wird. Die Verifizierung ist nahezu identisch mit der Verifizierung während der Erstellung eines Benutzer-Accounts (siehe Kapitel Registrierung eines Benutzer- Accounts auf Seite 3) bis auf die folgenden Unterschiede: Pro Benutzer-Account kann es nur eine offene Anfrage zum Zurücksetzen des Account-Passworts geben. Der Nutzer muss den Vorgang zum Zurücksetzen seines Account-Passworts innerhalb von 24 Stunden abschließen. Seite 4 von 8

5 Abbildung 3 - Zurücksetzen des Account-Passworts Zugangscode Um den Zugriff auf die App zu schützen, kann ein Nutzer optional während der Registrierung oder später in den Einstellungen einen Zugangscode vergeben. Der Zugangscode kann entweder ein einfacher, 4-stelliger Code oder ein komplexer Code aus 4 oder mehr alphanumerischen Zeichen sein. Der Nutzer muss diesen Zugangscode eingeben, wenn er die App neu startet, nachdem sie vom Nutzer selbst oder über die Speicherverwaltung des Geräts geschlossen wurde. Der Zugangscode kann jederzeit geändert und wieder deaktiviert werden. Wenn der Zugangscode während der Registrierung vergeben wird, wird er zusätzlich zum Verschlüsseln des Schlüssels der lokalen Datenbank verwendet (siehe auch Kapitel Lokale Verschlüsselung auf Seite 5). Die Vergabe oder das Ändern des Zugangscodes nach der Registrierung hat keinerlei Auswirkungen auf die Verschlüsselung. Verschlüsselung Lokale Verschlüsselung Alle Kontakte, Passwörter und Instant Messages werden verschlüsselt in einer Datenbank gespeichert. Zur Verschlüsselung wird SQLCipher mithilfe AES-256 [8] im CBC-Modus [9] verwendet. Der Schlüssel für die Datenbank ist eine zufällige Byte-Sequenz, die während der Registrierung erzeugt wird. Der Schlüssel wird wiederum mit einem eigenen Schlüssel verschlüsselt, welcher entweder aus dem benutzerdefinierten Zugangscode (siehe auch Kapitel Zugangscode ) oder - falls der Nutzer während der Registrierung keinen Zugangscode vergeben hat - aus einem zufälligem Code abgeleitet wird. Auf den Code wird PBKDF2 [10] mit einer Iteration von angewendet. Die ersten 32 Byte des Ergebnisses dienen Verifizierungszwecken. Die folgenden 32 Byte werden als SQLCipher-Schlüssel verwendet. Alle Dateien (Bilder, Videos, Dokumente und Sprachnachrichten), die als Instant Messages gesendet werden, werden mit AES-256 im CBC-Modus verschlüsselt. Dazu wird pro Datei ein zufällig generierter Schlüssel verwendet, der mit einem zufälligen Initialisierungsvektor kombiniert wird. Die verschlüsselte Datei wird im internen Speicher des Geräts gespeichert. Seite 5 von 8

6 Ende-zu-Ende-Verschlüsselung Ende-zu-Ende-Verschlüsselung bei ginlo bedeutet nicht nur Transportverschlüsselung auf Basis von TLS, sondern auch asymmetrische Verschlüsselung: Für jeden Nutzer wird während der Registrierung auf Basis von Elliptic Curve Cryptography (ECC) [11] ein öffentlicher und ein privater Schlüssel erzeugt. Obwohl zwischen den beiden Schlüsseln eines Schlüsselpaares ein mathematischer Zusammenhang besteht, kann der private Schlüssel nicht aus dem öffentlichen Schlüssel errechnet werden. Sämtliche Kommunikation zwischen ginlo Nutzern sowie die verschlüsselten Server-Backups werden mit dem asymmetrischen Verfahren verschlüsselt. Schlüsselerzeugung Der Client erzeugt mithilfe der Elliptic Curve Curve25519 [12] ein zufälliges Schlüsselpaar. Curve25519 ist eine von Sicherheitsexperten empfohlene Kurve. Gegen die vom National Institute of Standards and Technology (NIST) empfohlenen Kurven mehren sich in Sicherheitskreisen die Bedenken hinsichtlich der mit ihnen erzeugten Schlüssel sowie anderer potenzieller Schwachstellen [13]. Der private und öffentliche Schlüssel wird in der verschlüsselten Datenbank auf dem Client gespeichert (siehe auch Kapitel Lokale Verschlüsselung ). Der öffentliche Schlüssel wird außerdem an den ginlo Server geschickt. Schlüssel-Backup Für die Installation von ginlo auf einem anderen Gerät oder die Wiederherstellung der ginlo Inhalte im Falle von Beschädigung oder Verlust des Geräts ist ein Backup des privaten Schlüssels erforderlich. Da es keine anderen Möglichkeiten gibt, einen verlorenen privaten Schlüssel wiederherzustellen, wird dem Nutzer empfohlen, ein Backup zu erstellen. Ein Backup kann wie folgt erstellt werden: 1. Der Nutzer entscheidet, welche Art von Backup er erstellen möchte: 1. Ein Backup, das auf dem ginlo Server gespeichert wird 2. Ein lokales Backup, das der Nutzer sich z. B. an sein -Konto schickt oder in eine Datei kopiert 2. Der Nutzer vergibt ein Backup-Passwort, von dem ein AES-256-Schlüssel abgeleitet wird. Hiefür wird PBKDF2 mit einer Iteration von angewendet. Die Verschlüsselung des Backups erfolgt im CBC-Modus mit einem zufälligen Initialisierungsvektor. 3. Je nachdem, welche Art Backup der Nutzer wählt, wird das verschlüsselte Backup entweder auf den ginlo Server hochgeladen oder dem Nutzer zum Kopieren in eine Datei oder eine zur Verfügung gestellt. Verschlüsselung von ginlo Nachrichten (Instant Messages) Die Verschlüsselung von Instant Messages und Anfragen zwischen ginlo Nutzern basiert auf der Libsodium Library [14]: Jede Nachricht wird mit einem eigenen Zufallsschlüssel verschlüsselt, der auf Senderseite mithilfe der Libsodium-API crypto_secretbox_* erzeugt wird. Dieser Session Key wird mithilfe der Libsodium- API crypto_box_* mit dem öffentlichen Schlüssel des Empfängers verschlüsselt. Für Instant Messages, die als Teil einer Gruppenunterhaltung gesendet werden, erfolgt diese Art der Verschlüsselung für jeden einzelnen Teilnehmer der Unterhaltung. Verschlüsselung von als ginlo Nachrichten gesendeten Dateien (Instant Messages) Alle Dateien (Bilder, Videos, Dokumente und Sprachnachrichten), die als Instant Messages gesendet werden, werden auf dem Client des Absenders mit einem zufälligen 32-Byte-Schlüssel mithilfe von AES-256 im CBC- Modus verschlüsselt. Für jede Datei wird ein separater Schlüssel erzeugt. Dieser wird für jeden Empfänger mit dessen öffentlichem Schlüssel verschlüsselt. Sowohl die verschlüsselte Datei als auch der Schlüssel werden auf den Server transferiert, von wo aus der Client diese abrufen kann. Mithilfe des privaten Schlüssels des Empfängers entschlüsselt der Client den Dateischlüssel und kann damit wiederum die Datei entschlüsseln. Seite 6 von 8

7 s und Webchat Bitte beachten Sie, dass die Ende-zu-Ende-Verschlüsselung nicht für die s gilt, die Nutzer in ihren ginlo Unterhaltungen durch Hinzufügen des eigenen -Kontos in ginlo empfangen und senden können. Für das Übertragen dieser Nachrichten fungiert ginlo als zwischengeschalteter -Client. Aus diesem Grund können diese -Nachrichten nicht auf dieselbe Weise verschlüsselt werden wie ginlo Nachrichten. Sie sind jedoch während ihrer Übertragung über eine Transportverschlüsselung abgesichert, sofern diese vom E- Mail-Anbieter unterstützt wird (siehe auch Kapitel Transportverschlüsselung auf Seite 7). Ebenso können Nachrichten von und an -Empfänger, die an einer Unterhaltung über den ginlo Webchat teilnehmen, nur über eine Transportverschlüsselung abgesichert werden. Um allen Teilnehmer einer Gruppenunterhaltung diese Tatsache bewusst zu machen, sind externe Teilnehmer in der Teilnehmerliste grundsätzlich als solche markiert. Auch Unterhaltungen mit externen Teilnehmern sind in der Übersicht der Unterhaltungen entsprechend markiert. Transportverschlüsselung ginlo Client und ginlo Server kommunizieren über HTTPS mit TLS-Unterstützung. Der Server bestimmt die bevorzugte Reihenfolge der Cipher Suites und verwendet HTTP Strict Transport Security für die Kommunikation mit dem Client [15]. Benachrichtigungen ginlo bietet derzeit Push-Benachrichtigungen über GCM [16] und APNs [17]. Der Inhalt der entsprechenden Nachricht ist nicht in der Push-Benachrichtigung enthalten. Um Push-Benachrichtigungen zu erhalten, muss ein Client die Aktivierung von Push Tokens während der Registrierung des Accounts oder bei Hinzufügen zu einem Account anfordern. Abbildung 4 - Anfordern von Push Tokens Seite 7 von 8

8 Kontakt Der Schutz der persönlichen Daten unserer Nutzer steht bei uns an vorderster Stelle. Deshalb setzten wir bei der Entwicklung von ginlo die höchsten Sicherheitsstandards ein. Sicherheit ist jedoch kein Zustand, sondern ein Prozess. Falls Sie Schwachstellen in unserem Sicherheitskonzept finden, Ideen zu dessen Verbesserung oder Fragen haben, wenden Sie sich bitte an: Brabbler Secure Message and Data Exchange AG IT-Sicherheit Ria-Burkei-Straße 26 D München Quellen [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] NotificationsPG/APNSOverview.html Seite 8 von 8