StartMail Technisches White Paper

Transkript

1 StartMail Technisches White Paper Eigentümer Alex van Eesteren Version Datum

2 Inhaltsverzeichnis Vorwort.3 Überblick über StartMail Konstruktions-Erwägungen..4 Webmail vs. Desktop Client 4 Clientseitige vs. serverseitige Verschlüsselung.. 4 Clientseitige vs. serverseitige Schlüsselspeicherung...5 Leistung und Information zur Fehlerbehebung vs. Datenschutz.6 Open Source vs. Closed Source Software...6 Sicherheitsmaßnahmen. 7 Verfahren und Grundsätze...7 Entwicklungsprozess 7 Open Source.7 Kryptographie..8 Service-Architektur.. 8 Generelle Architektur..8 Webmail. 12 Wiederherstellung..15 IMAP und mobile Geräte.17 Automatische Deaktivierung von Geräten..17 Infrastruktursicherheit. 18 Fazit.18 Literaturhinweise.19 2

3 Vorwort In den letzten Jahren insbesondere im Jahr 2013 haben uns zahlreiche Ereignisse gezeigt, dass unsere Alltagskommunikation für Lauscher äußerst wertvoll ist. s gehören zu den heikelsten Services in puncto Datenschutz, die Nutzer online verwenden und es ist keine leichte Aufgabe, die Kommunikation privat zu halten. Zwar existieren bereits leistungsstarke Standards wie SSL / TLS und OpenPGP, doch die Verwendung und korrekte Einrichtung derselben kann für viele unerfahrene Nutzer schwierig sein. Da viele Menschen die Einrichtung und Verwendung von Verschlüsselung mit einer langwierigen Einarbeitungszeit assoziieren, kommunizieren sie weiterhin über unsichere Plattformen. Das Ziel von StartMail ist, dieses Problem zu lösen. Wir sehen Privatsphäre als fundamentales Menschenrecht an und haben uns der Aufgabe gestellt, dem Durchschnittsnutzer Privatsphäre und Sicherheit zu bieten. StartMail wurde entwickelt, um den Menschen zu helfen, ihr Recht auf Privatsphäre mithilfe leistungsfähiger Verschlüsselung für ihre tägliche -Kommunikation zurückzuerobern. StartMail wurde von den Menschen hinter den Privatsphäre-Suchmaschinen StartPage.com und Ixquick.com begründet. Die Entwicklung dauerte mehr als drei Jahre und war ein natürlicher Schritt vom Angebot einer privaten Internet-Suche hin zum Angebot für private und sichere - Kommunikation. Dieses Dokument erläutert die von uns getroffenen Entscheidungen in Bezug auf Sicherheitspraktiken und den Privatsphäre-Schutz unserer Nutzer. Zuerst bieten wir einen kurzen Überblick über unsere Leistungen, danach listen wir die wichtigsten Entscheidungen in Bezug auf unsere Erwägungen zur Konstruktion während der Gestaltung unserer Service-Architektur auf. Schlussendlich beschreiben wir die getroffenen Entscheidungen im Detail, mit dem Hauptaugenmerk auf sicherheitsorientierte Vorsichtsmaßnahmen und Funktionen. Überblick über StartMail StartMail ist eine Plattform für sichere -Kommunikation. Auf unseren Service kann sowohl von einem Web-Interface aus zugegriffen werden als auch über das traditionelle IMAP-Protokoll, das mit bestehenden -Clients kompatibel ist. Versierte Anwender mit ausreichend Wissen und Erfahrung können von der erweiterten Funktionalität profitieren: Zum Beispiel bietet StartMail diesen Nutzern die Möglichkeit, ihren Wiederherstellungscode selbstständig zu speichern, ihren bestehenden OpenPGP-Schlüssel zu importieren und zu verwalten oder auch alle Open PGP-Interaktionen manuell zu behandeln, um StartMail zur Übermittlungsplattform für ihre eigene sichere Kommunikation zu machen. Wir wollen sichere Kommunikation so transparent wie möglich machen. Zu diesem Zweck wird Open PGP verwendet. Versierte Nutzer haben die Möglichkeit, auf alle Kryptographie bezogenen Funktionen zu verzichten und ihre Kryptographie eigenständig zu behandeln und dann über IMAP auf ihre s zuzugreifen. Standardmäßig bietet StartMail jedoch die folgenden Sicherheitsfunktionen für Nutzerinnen: Asymmetrische Verschlüsselung und Signatur mit OpenPGP sowohl für StartMail- Nutzerinnen als auch für Nicht-StartMail-Nutzerinnen 3

4 Symmetrische (Frage & Antwort)-Verschlüsselung für Nutzer, die PGP nicht anwenden Operative Gesellschaft und Rechtsträger strikt außerhalb der US-Gerichtsbarkeit Speicherung von minimalen Daten über NutzerInnen und keinerlei Tracking-Cookies (siehe auch unsere strengen Datenschutzrichtlinien [1]) Alle dem Nutzer gehörenden Daten, einschließlich , Präferenzen und Anti Spam Profilen, werden im User-Tresor verschlüsselt gespeichert Eingehende s werden für spätere Übermittlung, wenn der Nutzer seinen User-Tresor öffnet sofort mit dem öffentlichen Schlüssel des Warteschlangen-Schlüsselpaars verschlüsselt. Konstruktions-Erwägungen Während der Entwicklung von StartMail wurden wir vor mehrere Herausforderungen in Bezug auf Sicherheit, Datenschutz und Benutzerfreundlichkeit gestellt. In diesem Abschnitt werden wir die relevantesten Entscheidungen thematisieren. Webmail vs. Desktop-Client Unser Ziel bei der Entwicklung von StartMail war es, einen anfängerfreundlichen OpenPGP-Client zu erschaffen. Wir entschieden uns aus mehreren Gründen, einen Webmail-Client statt einer Desktop (oder mobilen) Anwendung anzubieten. Erstens haben sich viele -Nutzer daran gewöhnt, über einen Browser auf ihre s zuzugreifen. Zweitens, da die Nutzer erwarten, von verschiedenen Geräten aus auf Ihre s zugreifen zu können, gestattet die Webmail Lösung eine Alternative zu OS-spezifischen Anwendungen und erlaubt ihnen, von der weiten Verbreitung zu profitieren, die Browser bieten. Schlussendlich gibt es bereits sichere OpenPGP kompatible Desktop-Clients, die für die Verwendung von StartMail über IMAP konfiguriert werden können. Die StartMail Web-Anwendung ist ein PGP-fähiger Mail-Client für das Web. Trotzdem unterstützen wir auch traditionelle -Clients, die mit IMAP funktionieren. Clientseitige vs. serverseitige Verschlüsselung Grundsätzlich können OpenPGP-Operationen (wie Ver- und Entschlüsselung) sowohl auf dem Server als auch auf dem Client erfolgen. In StartMail finden alle OpenPGP-Operationen serverseitig statt. Wir haben uns entschieden, Die Kryptographie auf dem Server durchzuführen, nachdem wir die clientseitige Möglichkeit gewissenhaft geprüft haben. Wir lehnten dies ab, weil OpenPGP- Operationen in einem Web-Browser in einem JavaScript-Kontext stattfinden, die absolut nicht die richtige Umgebung für Kryptographie ist. Matasano beschreibt in folgendem Artikel eine Reihe von zwingenden Gründen, warum dies der Fall ist: Zu den Gründen, clientseitige kryptographische Operationen abzulehnen, zählen Browser-JavaScript ist nicht bereit für die Kryptographie hinsichtlich der Programmierung von Primitiven wie eine zuverlässige Quelle von Zufallszahlen, mathematischen Funktionen usw. Die Formbarkeit der JavaScript-Laufzeitumgebung bedeutet, dass die Zukunftssicherheit von einem Teil eines JavaScript-Codes unmöglich zu gewährleisten ist: Der Server, der JavaScript bereitstellt, könnte leicht eine Hintertür im Code platzieren oder der Code selbst könnte während der Laufzeit durch ein anderes Script modifiziert werden. Dies verlangt von den 4

5 NutzerInnen das gleiche Maß an Vertrauen in den Server, der JavaScript bereitstellt, das sie in die serverseitige Kryptographie setzen. JavaScript wird in einer Umgebung ausgeführt (Browser), über das der Programmierer extrem wenig Kontrolle hat. Unter diesen Bedingungen ist es schwierig bis unmöglich, eine sichere Speicherverwaltung bereitzustellen, gegen Timing-Angriffe zu schützen, usw. bereitzustellen. In einfachen Worten: JavaScript ist eine schlechte Umgebung für den Umgang mit solch heiklen Operationen wie Kryptographie. Darüber hinaus kann ein JavaScript-Code, der in einem Browser läuft, auch von anderen Teilen eines im gleichen Browserfenster laufenden Teils eines JavaScript- Codes beeinflusst werden und manchmal sogar von anderen Webseiten. Diese Bedingungen machen es uns unmöglich, dass gleiche Maß an Sicherheit wie durch die Bereitstellung von serverseitiger Kryptographie zu gewährleisten. Ein häufig zitierter Vorteil der clientseitigen Kryptographie zumindest in der Theorie ist, dass weder der Server noch der -Anbieter Zugang zum privaten OpenPGP-Schlüssel des Users hat, was das benötigte Vertrauen des Users in den -Anbieter reduziert. In der Praxis ist dieser Sicherheitsvorteil jedoch illusorisch. Die einzige Gelegenheit, bei der private OpenPGP-Schlüssel tatsächlich nicht in Kontakt mit irgendeinem Server oder einem zur Verfügung gestellten Server-Code kommt ist, wenn die Kryptographie über eine native Desktop-Anwendung (z. B. GnuPG oder GPGtools) durchgeführt wird. StartMail unterstützt dies bereits vollständig mittels IMAP. Clientseitige Kryptographie-Operationen in einem Webbrowser, die JavaScript nutzen, bieten nur einen oberflächlichen Schutz vor einem Server, der gefährdet ist oder böswillige Absichten verfolgt. Dies liegt daran, dass der ausgeführte JavaScript-Code direkt von jenem Server empfangen wird. Auf diese Weise wird der Browser zu einer serverseitigen Erweiterung für bestimmte Operationen. Wir sehen die Client-Seite (Browser) vs. Server-Seite-Debatte als sich verändernde Größe und werden weiterhin nach technologischen Errungenschaften Ausschau halten, die es uns ermöglichen, unsere Entscheidung zu überdenken. Vor allem im Bereich browserbasierter Kryptographie verändern sich die Verfügbarkeit und die Qualität der Programmbibliotheken sehr schnell. Wir werden die Umsetzung einer clientseitigen Lösung in Erwägung ziehen, sobald Browser-Systeme und verfügbare Software zur nötigen Reife weiterentwickelt wurden, um vertrauenswürdige kryptographische Operationen zu unterstützen. Die Vertrauensfrage bleib immer, egal ob OpenPGP-Operationen nun im Browser oder auf dem Server stattfinden. Aus diesem Grund glauben wir, dass die echte Client-Seite (native Desktop) die sicherste Option ist. Sie gibt den Anwendern die vollständige Kontrolle über ihre OpenPGP-Schlüssel- Verwaltung und Kryptographie-Operationen in einer Umgebung, die für diesen Zweck besser geeignet ist als der Browser. Es existieren nach wie vor offensichtliche Probleme mit der Anwendererfahrung, der Setup-Komplexität und einem möglichen Datenverlust in Desktop-Clients. Da die volle Kompatibilität bei der Verbindung zu StartMail via IMAP gewährleistet ist, wollen wir auch die sicherste browser-basierende Lösung anbieten, die möglich ist. Clientseitige vs. serverseitige Schlüsselspeicherung Unabhängig davon, wo die Verschlüsselung und Entschlüsselung stattfinden, ist eine Diskussion über OpenPGP-Schlüsselspeicherung in Ordnung. Clientseitige Schlüsselspeicherung bedeutet, dass der private OpenPGP-Schlüssel dauerhaft auf dem Computer des Anwenders gespeichert wird (im Gegensatz zur Speicherung auf dem Server). Die Anwender speichern den Schlüssel entweder dauerhaft im Browser oder sie tragen ihren Schlüssel mit sich und stellen ihn bei Bedarf dem Browser zur Verfügung. Browser verfügen über keine sichere Möglichkeit, OpenPGP-Schlüssel zu speichern, die unsere Standards erfüllen. Darüber hinaus verwendet die große Mehrheit der Menschen noch immer veraltete 5

6 Browser. Was in anderen Zusammenhängen mit Graceful Degradation [2] gelöst werden könnte [2] (z.b. das Zurückgreifen auf eine alternative CSS-Eigenschaft, wenn der Browser die neuere nicht unterstützt), ist in einem Sicherheitsmodell einfach keine Option. Bis diese Situation nicht besser ist, bevorzugen wir, die PGP-Schlüssel unserer Anwender nicht den Gefahren der Lagerung im Browser auszusetzen. Zumal wir uns aus den oben beschriebenen Gründen für den serverseitigen Ansatz für den Umgang mit kryptographischen Operationen entscheiden haben, sehen wir kein überzeugendes Argument, die Schlüssel Browsern preiszugeben. Es ist wohl nicht notwendig zu erwähnen, dass die Idee, dass Anwender ihre OpenPGP-Schlüssel mit sich tragen, ein potentielles Sicherheitsrisiko darstellt. Nicht versierte Anwender hätten weder das Wissen noch die Geduld, um die notwendigen Vorkehrungen zu treffen, dass ihre Schlüssel nicht überflüssig vervielfacht oder unsicher gelagert werden. Leistung und Information zur Fehlerbehebung vs. Datenschutz Das Behalten eines Protokolls von Aktivitäten auf unseren Servern kann sehr nützlich für Fehlerbehebungen, Leistungs- und Sicherheitsverbesserungen sein. Doch bei der Entscheidung, welche Daten protokolliert werden, entscheiden wir immer zu Gunsten der Privatsphäre und Sicherheit unserer Nutzer. Ein Beispiel hierfür ist unser Ansatz im Umgang mit Spamfilter-Profildaten. Zusammen mit den Standard-Algorithmen verwenden wir Metadaten, um reale Beispiele zu erhalten, was Nutzer als Spam ansehen und was nicht. Wir haben uns entschieden, diese Informationen im persönlichen Tresor des Nutzers zu speichern (nachfolgend beschrieben), anstatt sie allgemein zu speichern, um die gesamte Effektivität unserer Spamfilter zu verbessern. Etwas anderes zu tun würde bedeuten, dass Teile von E- Mails unserer Nutzer dem ganzen System zur Verfügung stünden, was unsere oberste Priorität die Verpflichtung zur Privatsphäre, verletzen würde. Eine ähnliche Situation besteht bei der Suchindexierung. Damit die Suchfunktion schnell reagieren kann, müssen s indexiert werden und die Indizes müssen aktuell sein. Dies kann zu jedem Zeitpunkt geschehen, vorausgesetzt es geschieht bereits, bevor der Nutzer eine Suche startet. Im Falle von StartMail können die Suchindizes nur aktualisiert werden, wenn der Nutzer eingeloggt ist. Ist er nicht eingeloggt, sind s und Indizes verschlüsselt im User-Tresor gespeichert und die Indexierungsoperationen können nicht stattfinden. Diese Einschränkung, die uns zur Indexierung von s ausschließlich nach dem Login beschränkt, bietet für unsere Nutzer bessere Privatsphäre und Sicherheit, während sie nur einen kleinen Nachteil in der Funktionalität mit sich bringt. Open Source vs. Closed Source Software StartMails Quellcode setzt sich aus Open Source- und Closed Source-Komponenten zusammen. Die Open Source-Komponenten bestehen hauptsächlich aus infrastrukturellen Codes (beispielsweise Linux Betriebssystem und OpenPGP Cryptographic Suite) sowie Bibliotheken für unsere Web-Anwendung, wie zum Beispiel jquery und AngularJS. Der Code, den wir geschrieben haben, um den Webmail- Service bereitzustellen, die User-Tresore verwalten zu können und Redundanzen zu bieten, ist Closed Source. Open Source-Codes bieten gewisse Vorteile in Sachen Sicherheit, da eine Vielzahl von Menschen Zugriff auf den Quellcode haben und helfen können, ihn noch sicherer zu machen, indem sie Audits durchführen und Sicherheitslücken melden. Wir glauben allerdings, dass diese Vorteile nur bei Großprojekten zutreffen, die von einer etablierten Community unterstützt werden. Wenn ein Projekt noch zu klein ist, um die Aufmerksamkeit externer Sicherheitsexperten zu gewinnen, kann das Veröffentlichen des Quellcodes Risiken bergen, die jegliche Vorteile bei Weitem überwiegen. Potenzielle Angreifer gewinnen auf diesem Wege eine mächtige, zusätzliche Waffe: Den Quellcode der Anwendung. 6

7 Aus diesem Grund haben wir beschlossen, unseren Quellcode nicht zu veröffentlichen und unabhängige Prüfer zu engagieren, die unsere Datenschutz- und Sicherheitsmaßnahmen belegen sollen. Wenn StartMail wächst, kann es durchaus dazu kommen, dass die Vorteile bei einer Veröffentlichung unseres Quellcodes gegen etwaige Risiken überwiegen und wir unsere Entscheidung noch einmal überdenken. Sicherheitsmaßnahmen Im letzten Abschnitt beschrieben wir die Design-Entscheidungen, die im Laufe der Entwicklung von StartMail getroffen wurden. In diesem Abschnitt begutachten wir nun die Sicherheitsmaßnahmen, die die Organisation, Entwicklung, Instandhaltung und Systemarchitektur beeinflussen. Prozesse und Prinzipien Die Priorität von StartMail lag von Anfang an ganz klar bei Sicherheit und Datenschutz. Doch egal wie sicher ein System in der Theorie auch ist, wenn ein kritischer Dienst Schwachstellen aufweist, können Angreifer selbst sorgfältig durchdachte Sicherheitsmaßnahmen überwinden. Mit diesem Gedanken im Hinterkopf starteten wir einen sicherheitsorientierten Entwicklungsprozess, um gewährleisten zu können, dass keine Schwächen im System auftreten, wenn sich der Code in der Entwicklung befindet oder instandgehalten wird. Des Weiteren etablierten wir zahlreiche Verteidigungsschichten, um mögliche Schäden so gering wie möglich zu halten. Entwicklungsprozess Ein sicherer Code ist ohne Frage die Top-Priorität in einem Projekt wie StartMail. Natürlich existieren diverse Maßnahmen, um die Folgen potentieller Schwachstellen zu schmälern. Wir haben eine Reihe davon etabliert, um sicherzustellen, dass sowohl interne als auch externe Prüfer eine objektive Einschätzung des StartMail Codes gewinnen können: Die Programmierer, die an StartMail arbeiten, wurden für sichere Entwicklung ausgebildet und haben Erfahrung auf dem Gebiet. Ein qualitativ hochwertiger, gut strukturierter und lesbarer Code ist essentiell in Sachen Sicherheit. Darum geben wir unser Bestes, um zu gewährleisten, dass Gutachter die Struktur und Funktionsweisen unseres Codes problemlos verstehen und sich auf das Finden von Schwachpunkten konzentrieren können. Jede Codezeile wird von mehreren, voneinander unabhängigen Entwicklern auf Qualität und Sicherheit geprüft, ehe sie der Codebasis hinzugefügt wird. Entdeckte Probleme in dieser Phase resultieren in der Ablehnung des Codes: Er kann nicht in den Quellcode aufgenommen werden, bevor der Fehler nicht berichtigt wurde. Sicherheitsexperten, die nicht zum Entwickler-Team gehören, führen Sicherheits-Audits des Codes durch. Dasselbe gilt für externe Bibliotheken. Die Entwicklungs-Infrastruktur (code repository, issue tracker, review tooling) kommt ausschließlich beim StartMail-Projekt zum Einsatz und ist nur für Teammitglieder und Begutachter zugänglich. Open Source Wir glauben, dass die Verwendung von Open Source Bibliotheken und Werkzeugen im Gegensatz zu jenen, die von kommerziellen Instanzen kontrolliert werden, oft die sicherere Wahl ist. Stabile Communitys stehen hinter der Entwicklung solcher Werkzeuge und die frei zugängliche Quelle erlaubt uns eine interne Prüfung, bevor wir uns dazu entschließen, sie in unsere Anwendung 7

8 einzubinden. Das ist der Hauptgrund, weshalb wir, zusätzlich zu dem Code, den wir selbst schreiben, ausschließlich Gebrauch von Open Source-Komponenten machen. Nachdem die Entwickler dieser Werkzeuge Unterstützung brauchen, um ihre Arbeit fortführen zu können, hat StartMail bereits an mehrere Open Source-Projekte gespendet, darunter auch LibreSSL [3]. Kryptografie Das Rad in Sachen Kryptografie (und Sicherheit im Allgemeinen) neu zu erfinden, ist immer eine schlechte Idee [4]. Es ist nicht bloß unnötig, sondern auch potentiell gefährlich. Die Geschichte zeigt, dass man in der Kryptografie am besten auf Standardwerkzeuge- und Bibliotheken sowie bewährte Algorithmen zurückgreift, die der genauen Prüfung der akademischen und Open Source Communities standgehalten haben. Die meisten Entwickler sind sich dessen bewusst, doch das eigentliche Problem ist recht nuanciert. Neben den Dingen, die wir am besten Kryptografie-Experten überlassen, stechen diese Kategorien am meisten hervor: 1. Kryptografie-Algorithmen für Verschlüsselung, Entschlüsselung, und Hashing. AES, RSA oder SHA-2 sollten nicht ersetzt werden. 2. Kryptografische Protokolle wie PBKDF2, HMAC, SSL, und diverse PKCS-Standards. Selbst beim Verwenden bewährter kryptografischer Algorithmen ist es normalerweise unklug, neue Schemata einzubringen. 3. Kryptografische Implementierungen. Auch, wenn man Gebrauch von kryptografischen Muster-Algorithmen macht und sich im Rahmen des bewährten Protokolls bewegt, ist eine Implementierung niemals unerheblich. Solche Aufgaben überlassen wir Open Source- Bibliotheken, die von einer Community geprüft werden. Im Fall von OpenSSL, dem viel zu wenig Aufmerksamkeit seitens der Sicherheits-Community [5] geschenkt wurde, verfolgen wir die Entwicklungen genau und ziehen in Betracht, OpenSSL so bald wie möglich durch einen geeigneten Ersatz abzulösen. Service Architektur Der vorherige Abschnitt beschäftigte sich mit Sicherheitsmaßnahmen und Verfahren innerhalb der Organisation. Natürlich gibt es eine ganze Reihe solcher Sicherheitsmaßnahmen. In diesem Abschnitt werfen wir nun einen Blick auf die drei bemerkenswertesten Aspekte (beachten Sie bitte, dass diese Liste unvollständig ist): Die allgemeine Architektur, das Webmail und, zu guter Letzt, IMAP. Generelle Architektur SSL und PFS Um mit unseren Nutzern sicher kommunizieren zu können, verschlüsseln wir jede Verbindung, die das TLS-Protokoll verwendet. Die genauen Details der Verschlüsselung einer Verbindung zu StartMail hängen davon ab, worauf sich Server und Client während des Errichtens der TLS-Verbindung einigen. Durch das Einrichten sicherer Präferenzen haben alle Clients, die diese Anforderungen erfüllen (was auf alle bisherigen Clients zutrifft), eine sichere Verbindung zu uns. Unsere Server wurden mit den folgenden Anforderungen ausgestattet: Erlaube (und bevorzuge) ein wichtiges, kryptografisches Merkmal namens Perfect Forward Secrecy (PFS). Die Wichtigkeit von PFS wird unten erläutert. In der Praxis heißt das, dass unsere Server Dife Hellman-basierte Authentifizierungs-Chiffren wie ECDHE bevorzugen. Nur Support Hashing Algorithmen, die keine bekannten, ausnutzbaren Schwachpunkte aufweisen, also kein MD5. 8

9 Bevorzuge den Gebrauch der neuesten Version von TLS: 1.2. Dies erlaubt uns das Benutzen stärkerer Verschlüsselungschiffren (wie beispielsweise AES-GCM) und schützt vor den meisten Attacken auf Blockchiffren, die im Laufe der letzten zwei Jahre veröffentlicht wurden. Bevorzuge starke Blockchiffren (AES-GCM) über RC4. Für Rückwärtskompatibilität mit älteren Clients sind beide verfügbar, wenn aber ein neuerer Client eine Verbindung herstellt, wird AES-GCM genutzt. Verwende mindestens 128 Bit Schlüsselmaterial in Blockchiffren und Streamchiffren (AES- GCM and RC4). Für eine vollständige Auswertung unserer TLS-Verbindung und Praktiken lesen Sie bitte unseren SSL Labs-Report [6]. In jedem Fall, in dem PFS nicht verwendet wird, besteht das Risiko, dass der frühere, verschlüsselte Verkehr gefährdet wird. Das kann passieren, wenn der private Schlüssel eines Systems (sei es durch Hacking, Diebstahl, oder eine Regierungsorganisation) kompromittiert wird und die Personen, die den Schlüssel erbeutet haben, im Besitz von Aufzeichnungen des früheren Verkehrs zwischen Client und Server sind. Perfect Forward Secrecy schützt vor dieser Bedrohung, indem es verhindert, dass der bisherige Verkehr entschlüsselt wird, selbst wenn der Schlüssel kompromittiert wurde. StartMail verwendet SSL-Zertifikate von SwissSign, einem Schweizer Zertifizierer im Besitz der Schweizerischen Post (einer Regierungsorganistion). Ein Zertifizierungs-Unternehmen außerhalb der USA gibt uns mehr Sicherheit, dass StartMail Zertifikate nicht durch eine Regierungsanordnung kompromittiert werden. Verschlüsselung bei Übertragung und Speicherung Alle Verbindungen zu (und zwischen) StartMail-Servern sind durch eine TLS-Verschlüsselung geschützt. Obwohl die Verbindung während der Übertragung verschlüsselt ist, empfehlen wir, die E- Mails mithilfe von OpenPGP selbst zu verschlüsseln, sodass sie verschlüsselt auf dem Server gelagert oder gefahrlos an weniger seriöse Anbietern geliefert werden können. OpenPGP ist besonders sinnvoll, was die Kommunikation mit anderen anbelangt, deren -Provider sich nicht dem Datenschutz und der Sicherheit verschrieben haben und wenn Nutzer ihre Mails über IMAP abrufen (und dementsprechend Kopien ihrer s auf einem Gerät speichern). Das folgende Diagramm illustriert den Unterschied zwischen dem Verschlüsseln der Verbindung und dem Verschlüsseln der eigentlichen Daten, und warum beides wichtig ist. 9

10 10

11 Header-Stripping Eine weiteres Feature in Sachen Privatsphäre ist unsere Header-Stripping-Funktion für ein- und ausgehende Mails. Sowohl für ein- als auch für ausgehende s haben wir folgende Maßnahmen ergriffen: Verschleierung lokaler IP-Adressen und Hostnamen der StartMail-Infrastruktur. Zurückweisen von s, die von gesperrten Absenderadressen kommen. Zum Beispiel E- Mails die angeblich von oder ähnlichen Adressen eingehen. Speziell für ausgehende s befreien wir die Header von folgenden Informationen: User-Agent X-Mailer Ursprungs-IP X-Enigmail-Version X-Virus-Scanned X-Pgp-Agent Erhalten Mime-Version Ratenbegrenzung Wir haben Ratenbegrenzungs-Features etabliert, um das System vor Passwort brute-forcing (Ausprobieren verschiedener Passwörter) und username enumeration (Aufzählen von Benutzernamen) zu schützen. Durch eine kurzzeitige (weniger als eine Stunde) Speicherung von IP-Adressen werden potenzielle Angreifer identifiziert und die Versuche, Passwörter zu erraten, reduziert. Dies geschieht natürlich im Rahmen unserer Datenschutzerklärung. User-Tresor Userdaten werden in sogenannten User-Tresoren gespeichert, die im Grunde nichts anderes sind als komplett verschlüsselte LUKS (Linux Unified Key Setup ) volumes. Nachdem Nutzer ihre Passphrase eingegeben haben, haben sie für die Dauer der Session Zugriff auf ihre Inhalte. Ist der Tresor geschlossen, kann keine Person auf dessen Inhalte zugreifen, selbst wenn sie anderweitig Zugang zum Server hat. Aufgrund unseres User-Tresor-Systems müssen wir weder die Passwörter unserer Nutzer noch zerlegte Versionen derselben speichern also tun wir es nicht. Anstatt das Passwort eines Users zu überprüfen, verwenden wir es ganz einfach für dessen Versuch, den Tresor zu öffnen. Gelingt es, war das Passwort korrekt. Selbstverständlich sind entsprechende Sicherheitsmaßnahmen vorhanden, die uns vor Timing-Angriffen schützen, wenn wir auf diese Art und Weise die Zugangsberechtigungen prüfen. Was lagern wir in User-Tresoren? Wir speichern die s der Nutzer und alle privaten Angaben zum Nutzerkonto im eigenen User- Tresor des Nutzers (Details finden Sie in unseren Datenschutzrichtlinien). Das bedeutet, dass jedes Mal, wenn ein Nutzer auf seinen Posteingang zugreifen will, er erst den Account, also seinen User- Tresor öffnen muss. 11

12 s werden im User-Tresor gelagert, sobald sie einen Account erreicht haben. Natürlich können Nachrichten, die eingehen, während der User offline ist, nicht zugestellt werden, ehe er seinen User- Tresor manuell öffnet, indem er sich einloggt. Nachdem wir wollen, dass ausschließlich Nutzer auf Daten zugreifen können, die sie auch besitzen, wird ein zusätzliches OpenPGP-Schlüsselpaar für jeden Nutzer generiert, das als "queue keypair" fungiert. Der private Schlüssel wird innerhalb des User-Tresors gespeichert und der öffentliche Schlüssel ist dem Mailer Service zugänglich. Wenn Post für einen Nutzer eintrifft, wird diese mithilfe seines queue's public key verschlüsselt und in einer Warteschlange gespeichert. Ist der Tresor erst einmal geöffnet (durch das Einloggen des Users), werden diese Mails vom queue's private key entschlüsselt und in den Posteingang des Nutzers verschoben. Hinweis: Das Queue-Schlüsselpaar ist *vollkommen getrennt* vom OpenPGP-Schlüsselpaar, das mit dem Account verbunden ist, den der Nutzer für seine Kommunikation nutzt. Natürlich ist der End-to-End-Schutz bereits gegeben, wenn der Absender der Nachricht sich dazu entschließt, sie mithilfe von OpenPGP zu verschlüsseln, was wir prinzipiell immer empfehlen. Der Prozess, den wir oben beschreiben, ist lediglich eine zusätzliche Absicherung. Spam-Metadaten StartMail ermöglicht den Nutzern, ihren bayesschen Spam-Filter zu konditionieren, indem sie s im Webmail-Interface als Spam kennzeichnen. Die mit dem Spamfilter-Training verbundenen Metadaten werden als sensible Nutzerdaten betrachtet, da sie zumindest einen Teil der Inhalte der E- Mails eines Users enthalten. Aus diesem Grund werden besagte Daten im Tresor aufbewahrt. Schlüsselbund Wenn sich Nutzer bereiterklären, von den OpenPGP-Features im StartMail Webmail-Interface Gebrauch zu machen, wird auch ihr Schlüsselbund im User-Tresor gespeichert. Sie können dann andere (öffentliche wie private) Schlüssel für die Kommunikation mit anderen Usern zu ihrem Schlüsselbund hinzufügen. Virus-Scanning Die meisten dienste scannen verschlüsselte Nachrichten nicht auf Viren. StartMail hingegen scannt verschlüsselte Nachrichten auf Viren, sobald sie durch das StartMail Web-Interface entschlüsselt wurden. Wird eine Nachricht entdeckt, die einen Virus enthält, so bleibt diese im Posteingang des Nutzers, wird aber unzugänglich (wobei man sie noch über IMAP herunterladen kann) und der Nutzer wird vor der Gefahr gewarnt. Webmail Symmetrische Verschlüsselung Man kann seine Nachrichten symmetrisch verschlüsseln, indem man während des Erstellens F&A als Verschlüsselungsoption wählt. 12

13 Das Senden einer F&A-Nachricht ist dem Senden einer verschlüsselten nicht unähnlich, mit nur ein paar Unterschieden: Die Nachricht wird von OpenPGP symmetrischer Verschlüsselung verschlüsselt, wobei die Antwort der Schlüssel ist. Im Gegensatz zu klassischen, asymmetrisch OpenPGP-verschlüsselten Nachrichten, die für alle öffentlichen Schlüssel der Empfänger verschlüsselt werden müssen, ist diese Art der Verschlüsselung für jeden Empfänger zugänglich selbst solche, die keinen öffentlichen OpenPGP Schlüssel importiert haben. Wenn der vorgesehene Empfänger der Nachricht kein Nutzer von StartMail ist, wird die Nachricht nicht als tatsächliche verschickt. Stattdessen: Wird sie verschlüsselt auf unseren Servern aufbewahrt. Eine Benachrichtigungs- wird dem Empfänger übermittelt. Diese Mitteilung beinhaltet einen Link zu einem StartMail-Server. Wenn der Empfänger auf den Link in der Benachrichtigungs-Mail klickt, erscheint die Frage des Absenders mitsamt einer Aufforderung, die richtige Antwort einzugeben. Die Antwort muss jener entsprechen, die vom Sender vordefiniert wurde. Der Empfänger hat bloß fünf (5) Versuche, die richtige Antwort einzugeben. Hat er alle Chancen vertan, ist die Nachricht nicht länger zugänglich. Dies ist eine Maßnahme gegen brute-forcing. Hat der Empfänger die richtige Antwort eingegeben, ist er oder sie imstande, die Inhalte der F&A-Nachricht einzusehen und - auf sicherem Wege - über dasselbe Interface eine Antwort zu verfassen. Wenn der Sender die OpenPGP-Funktion in StartMail aktiviert hat, wird die (mögliche) Antwort mit dessen öffentlichem Schlüssel asymmetrisch verschlüsselt. Ist der vorgesehene Empfänger ein StartMail-User, wird die Nachricht intern als normal verschlüsselte Nachricht verschickt. Die in StartMail eingebettete OpenPGP-Funktion erlaubt dem Empfänger, die Nachricht über das Web-Interface durch das Beantworten einer Frage zu entschlüsseln. Als zusätzliche Sicherheitsmaßnahme werden F&A-Nachrichten nach drei Tagen automatisch von den StartMail-Servern gelöscht. Wir entwickeln gegenwärtig eine Funktion, die es Nutzern ermöglichen soll, eine andere (längere oder kürzere) Zeitspanne für das Ablaufen ihrer Nachrichten festzulegen. In jedem Fall werden F&A-Nachrichten nach Ablaufen des entsprechenden Zeitfensters gelöscht. OpenPGP Wir bieten OpenPGP-Funktionen [7] in unserem Webmail-Interface an. OpenPGP ist ein Standard- Protokoll, näher beschrieben in RFC 4880 [8]. Laut dem OpenPGP-Standard werden zwei separate Schlüssel für das Ver- und Entschlüsseln von Daten verwendet. Jeder Nutzer hat sein eigenes Schlüsselpaar: Einen privaten Schlüssel, der zusammen mit einem geheimen Passwort verwendet wird, um Daten und Dateien zu entschlüsseln, und einen öffentlichen Schlüssel, der an andere weitergegeben wird. Nachrichten mit einem speziellen öffentlichen Schlüssel können ausschließlich mit dem entsprechenden privaten Gegenstück entschlüsselt werden. Hat ein Nutzer OpenPGP-Funktionen aktiviert, wird er dazu aufgefordert, entweder ein neues Schlüsselpaar zu generieren, oder ein bereits bestehendes zu importieren. Neue OpenPGP-Schlüssel 13

14 Wir verwenden das Standard-GnuPG-Tool, um neue Schlüsselpaare (privat und öffentlich) auf unseren Servern zu generieren. Die -Adresse eines Schlüsselpaares ist selbstverständlich die Adresse des Nutzers. Die von StartMail generierten Schlüssel sind 4096-bit RSA-Schlüssel. Importierte OpenPGP-Schlüssel Nutzer, die bereits ein OpenPGP-Schlüsselpaar besitzen, können dieses in StartMail importieren. Derzeit muss die StartMail-Adresse dem Schlüsselpaar vor dem Import zugeordnet werden. Wir arbeiten an einer Funktion, die es den Nutzern ermöglicht, ihre StartMail-Adresse ihrem vorhandenen Schlüssel hinzuzufügen. OpenPGP Schlüssel-Management Das grundlegende Schlüssel-Management ist in der Web-Anwendung von StartMail verfügbar: Ändern der privaten Schlüssel-Passphrase Schlüssel importieren/exportieren Dem Schlüsselpaar zugeordnete -Adressen hinzufügen/entfernen (demnächst) Schlüssel widerrufen/neu generieren Passphrasen zwischenspeichern Passphrasen Zwischenspeicherung Der private OpenPGP-Schlüssel ist verschlüsselt auf dem Server im User-Tresor gespeichert. Zusätzlich ist der Schlüssel selbst immer mit einer Passphrase verschlüsselt. Die Verwendung von OpenPGP im Web-Interface bedeutet, dass die Passphrase des privaten Schlüssels der Applikation zur Verfügung stehen muss, sodass Verschlüsselungs- und Entschlüsselungs-Operationen auf dem Server stattfinden können. Wann immer die Passphrase benötigt wird, werden die Nutzer zur Eingabe aufgefordert und können optional wählen, dass sie in Erinnerung bleibt. Die verfügbaren Optionen für die Zwischenspeicherung der Passphrase sind: Niemals 5 Minuten 30 Minuten 120 Minuten Bis zum Logout Wenn die Zwischenspeicherung-Option gewählt wurde, wird die Passphrase verschlüsselt und im System des Servers gespeichert. Der Verschlüsselungs-Schlüssel für die Passphrase ist in einem Browser-Cookie gespeichert. Ein Angreifer, der Zugriff auf die Cookies eines Nutzers gewinnt, hat somit keine Möglichkeit, die Passphrase selbst zu erlangen. Natürlich ist die sicherste wenn auch etwas umständliche Option, die Passphrase überhaupt nicht zwischenzuspeichern. Aber diese Entscheidung überlassen wir unseren Nutzern. Open PGP-Schlüsselverzeichnis Wenn Nutzer ihre OpenPGP-Operationen von StartMail abwickeln lassen, wird der öffentliche Schlüssel automatisch in ein internes Schlüsselverzeichnis aufgenommen. Wenn der Nutzer eine verschlüsselte an einen anderen StartMail Nutzer erstellt, der ebenfalls OpenPGP in StartMail eingestellt hat, wird der öffentliche Schlüssel des Empfängers aus dem Schlüsselverzeichnis abgerufen. Nutzer können sich in ihren Präferenzen aus diesem Schlüsselverzeichnis abmelden. 14

15 Hinweis: Die öffentlichen Schlüssel werden nicht mit StartMail Nutzern geteilt noch sind sie öffentlich zugänglich. Sie werden nur verwendet, um die Kommunikation von StartMail Nutzern untereinander transparent zu verschlüsseln. Signieren und Verifizieren einer Signatur Zusammen mit -Verschlüsselung und Entschlüsselung bieten wir im StartMail Web-Interface die Möglichkeit, s mit OpenPGP Signaturen zu signieren. Das Signieren von s ist sehr wichtig: Es erlaubt, die Identität des Absenders zu überprüfen, indem garantiert ist, dass der Absender der verschlüsselten der Eigentümer des privaten Schlüssels ist, der mit seiner -Adresse übereinstimmt. Standardmäßig werden auch alle über das StartMail Web-Interface versendeten OpenPGP-verschlüsselten s signiert. Das StartMail Web-Interface liefert die visuelle Rückmeldung über die Gültigkeit der - Signaturen und warnt Nutzer, wenn sich Nachrichten mit einer ungültigen Signatur erhalten. Um die Signaturen anderer StartMail-Nutzer zu überprüfen, wird deren öffentlicher OpenPGP-Schlüssel automatisch von dem im vorigen Abschnitt erwähnten Schlüsselverzeichnis abgerufen. Zusätzlich erhalten die Nutzer jedoch die Möglichkeit, ihre öffentlichen OpenPGP-Schlüssel auf den MIT OpenPGP Schlüsselserver [9] hochzuladen. OpenPGP-Schlüsselbund im Tresor Wie bereits erwähnt ist eines der im User-Tresor gespeicherten Items der OpenPGP Schlüsselbund. Das ist wichtig, denn ohne den Tresor zu öffnen, steht das Schlüsselpaar des Besitzers dem System nicht zur Verfügung. Der Schlüsselbund enthält das Schlüsselpaar des Nutzers und alle anderen Schlüssel, die er hochgeladen oder importiert hat. Wiederherstellung Sollten Nutzer jemals die Passphrase ihres Accounts vergessen, bieten wir zwei Möglichkeiten, sie wiederherzustellen: Mit einem Wiederherstellungs-Code Mit einem Zurücksetzungs-Link an die Wiederherstellungs -Adresse Bei der Anmeldung können die Nutzer zwischen dem Beziehen eines Wiederherstellungs-Codes und dem Einrichten einer Wiederherstellungs -Adresse wählen. Der Wiederherstellungs-Code wird nur angeboten, wenn der User keine Wiederherstellungs -Adresse wählt. Wir entwickeln neue Funktionen, um auch jenen Nutzern einen Wiederherstellungs-Code anbieten zu können, die eine Wiederherstellungs -Adresse angegeben haben. Der Code kann als Backup nützlich sein, falls der Zugriff auf die Wiederherstellungs -Adresse nicht mehr möglich ist. Es ist wichtig zu beachten, dass unabhängig von der Wahl des Nutzers automatisch ein Code durch das System generiert wird. Wenn der Nutzer keine Wiederherstellungs -Adresse angegeben hat, wird StartMail den Code nicht speichern: Der Nutzer selbst ist für die Aufbewahrung voll verantwortlich. Falls der Nutzer eine Wiederherstellungs -Adresse nennt, wird StartMail den Code verschlüsselt speichern. Wir erklären diesen Prozess detailliert in diesem Abschnitt. Wiederherstellung mit einem Wiederherstellungscode Der bei der Anmeldung erhaltene Wiederherstellungscode kann verwendet werden, um das Konto manuell zurückzusetzen, falls der Nutzer seine Konto-Passphrase vergisst. StartMail speichert keine Wiederherstellungscodes für Konten, die keine Wiederherstellungs - Adressen festgelegt haben. Aus diesem Grund können unsere Mitarbeiter keinen Nutzern weiterhelfen, die ihren Wiederherstellungscode verloren haben. Es ist uns technisch nicht möglich, Konten manuell 15

16 zurückzusetzen und selbst wenn es möglich wäre, hätten wir keine Möglichkeit, die Identität der Person zu überprüfen, die um Zurücksetzung gebeten haben. Einen Wiederherstellungscode auf diese Weise herauszugeben würde bedeutet, dass sich die Verantwortung für sichere Speicherung zum Nutzer hin verschiebt. Wir empfehlen, dass technisch weniger versierte Anwender, die eventuell Schwierigkeiten beim sicheren Speichern des Wiederherstellungscodes haben könnten, eine Wiederherstellungs -Adresse angeben und StartMail das Speichern und Wiederherstellen für sie erledigen lassen, falls dies nötig sein sollte. Wiederherstellung mit einer Wiederherstellungs-Adresse Adressprüfung Nach der Anmeldung und dem Festlegen einer Wiederherstellungs-Adresse wird eine Überprüfungs- an die Wiederherstellungs-Adresse gesendet. Es ist sehr wichtig, diese zu bestätigen, da dieser Schritt StartMail erlaubt, das Besitzrecht an der -Adresse zu prüfen, die zur Wiederherstellung angegeben wurde. Sobald die Adresse geprüft ist, kann der Nutzer damit das Zurücksetzen beantragen, sollte es nötig sein. Hinweis: Die Nutzer müssen Ihre Wiederherstellungs -Adresse bestätigen, bevor Sie versuchen, Ihr Konto zurückzusetzen. Andernfalls sind wir nicht in der Lage, mit dem Prozess fortzufahren. Speicherung des Wiederherstellungscodes Der Wiederherstellungscode wird automatisch vom Server generiert und unter Verwendung multipler Verschlüsselungsschichten in einer OpenPGP-verschlüsselten Datei gespeichert (im nächsten Abschnitt wird erklärt, warum dies wichtig ist). Niemand, inklusive StartMail Support-Mitarbeiter oder Administratoren, hat Zugriff zum unverschlüsselten Wiederherstellungscode oder kann manuell einen, einem beliebigen Konto zugehörigen, Wiederherstellungscode erzeugen. Wir halten es für sehr wichtig, den Wiederherstellungscode vor menschlichem Zugriff zu schützen. Der Wiederherstellungscode verleiht jedem, der ihn besitzt, die Macht, das Passwort eines Kontos zurückzusetzen. Ein Angreifer, der im Besitz eines solchen Codes wäre, könnte das Konto vollständig übernehmen. Wir ergreifen jede notwendige Vorsichtsmaßnahme um sicherzustellen, dass ihn nur der rechtmäßige Besitzer erhält. Zum Entschlüsseln wird mehr Personen als eine benötigt Der Genehmigungsprozess für eine Wiederherstellungsanforderung ist nicht vollständig automatisiert. Für die Entschlüsselung und um die Anfrage zu bestätigen werden zwei verschiedene, hochrangige Mitglieder des Management-Teams benötigt (um eine Verschlüsselungsschicht zu entfernen). Die beteiligten Personen befinden sich auf verschiedenen Kontinenten (Europa und USA), um sie unter verschiedenen Rechtsordnungen zu halten. Dies ist nötig, um zu verhindern, dass eine einzelne Person die Macht hat, einen Antrag zu genehmigen. Sollte eine Person von einer Behörde kompromittiert werden, ist für die Kontowiederherstellung immer eine zusätzliche Interaktion erforderlich. Sobald der zweite Manager die Wiederherstellungsanforderung anerkannt und das Wiederherstellungsfile mit seinem Schlüssel entschlüsselt hat, wird das daraus resultierende File an das StartMail System weitergeleitet, das für die Entfernung der letzten Verschlüsselungsschicht verantwortlich ist und den Wiederherstellungscode an den Benutzer, der ihn beantragt hat, versendet. 16

17 Kontowiederherstellung Der Kontowiederherstellungs-Prozess erfordert die Passwortänderung eines User-Tresors. Der Tresor ist ein LUKS Volume [10] mit mehreren Slots: Ein Slot wird für die Authentifizierung verwendet, ein anderer für die Wiederherstellung. Eine erfolgreiche Wiederherstellung hat folgendes Ergebnis: Der Tresor wird mit dem Key, der dem Wiederherstellungs-Slot entspricht, aufgesperrt Die alte Authentifizierung wird überschrieben, indem ein neues Passwort eingegeben wird Der alte Wiederherstellungs-Slot wird überschrieben, indem ein neuer Wiederherstellungscode generiert wird. IMAP und mobile Geräte Anwender, die über einen separaten -Client zugreifen möchten, können dies immer über IMAP tun. Der IMAP-Zugriff ist standardmäßig deaktiviert und kann im Bereich Einstellungen aktiviert werden. Hinweis: Viele Nutzer verwenden für den Zugriff auf Ihre s von einem separaten E- Mail-Client das POP3-Protokoll. IMAP funktioniert auf eine sehr ähnliche Weise, ist aber so konzipiert, dass es Nachrichten so lange auf einem Remote-Server gespeichert hält, bis diese gelöscht werden, statt sie auf den Client-Rechner herunterzuladen und vom Server zu löschen. Dies gliedert sich natürlicher in das Anzeigen von s im StartMail Web-Interface ein und erlaubt den Anwendern, dennoch von der sicheren Speicherung zu profitieren, die das User-Tresor-System bietet. Wir empfehlen, jedes externe Gerät, das StartMail über IMAP verbindet, separat zu konfigurieren. Sobald Nutzer ein (benanntes) Gerät hinzufügen, erhalten sie einen einzigartigen Benutzernamen, ein Passwort und eine IMAP Serverinformationen-Kombination, um das Gerät zu konfigurieren. Das Erstellen von separaten IMAP Anmeldeinformationen für jedes Gerät ermöglicht es den Anwendern, die StartMail Anmeldeinformationen nicht mit der Software von Drittanbietern teilen zu müssen. Vom Sicherheitsstandpunkt aus gesehen hat dies mehrere Vorteile, falls eines der IMAP- Fähigen Geräte (Laptop, Telefon) kompromittiert ist: Ein Angreifer, der in Besitz von gültigen IMAP Anmeldeinformationen ist, hat nur Zugriff auf den Posteingang des Nutzers (Nachrichten). Es besteht keine Gefahr, dass das komplette StartMail-Konto in diesem Szenario von einem Angreifer übernommen werden könnte. IMAP-Konten können voneinander unabhängig deaktiviert werden. Das Erstellen von unterschiedlichen Passwörtern für jedes mit StartMail verbundenen Gerätes bietet auch einen Überblick, welche externen Dienste auf StartMail zugreifen. Sollte einer dieser Dienste für immer verloren oder veraltet sein oder nicht mehr verwendet werden, ist es einfach, das Gerät zu entfernen und den Zugriff zu entziehen. Automatisches Deaktivieren eines Gerätes Nach zahlreichen erfolglosen Authentifizierungsversuchen wird ein Gerät deaktiviert. Nutzer können überprüfen, ob ein Gerät deaktiviert ist, indem Sie sich in Ihr StartMail-Konto einloggen, auf die Seite Einstellungen Mobile/IMAP wechseln und überprüfen, ob das betreffende Gerät als deaktiviert markiert ist. 17

18 Sobald ein Gerät deaktiviert wurde, kann es nicht erneut aktiviert werden. Ein deaktiviertes Gerät muss entfernt werden und (optional) kann der Nutzer es als neues Gerät wieder hinzufügen. Infrastruktursicherheit Unsere Infrastruktur liegt in den Niederlanden und wurde gebaut, um die Sicherheitsanforderungen des StartMail-Services zu unterstützen. Als allgemeine Regel isolieren wir die Dienstleistungen und Komponenten so weit wie möglich von unseren Anwendungen, um den möglichen Schaden, den ein Angreifer anrichten kann, so gering wie möglich zu halten. So werden User-Tresore in Bezug auf die Infrastruktur auf anderen Servern als Web-Servern gespeichert. Sie kommunizieren miteinander über eine sehr begrenzte API, um die Schäden zu minimieren, die von jemandem angerichtet werden, der einen Web-Server kompromittiert. Darüber hinaus haben wir alle Standard-Sicherheitsvorkehrungen getroffen, die in einer sicheren Hosting-Umgebung erwartet werden wie interne (PFS) TLS-Kommunikation, strenge Firewalls, Festplattenverschlüsselung auf allen Maschinen usw. Wir haben auch zusätzliche Maßnahmen ergriffen, um Protokolle zu anonymisieren, wie sie im Detail in unserer Datenschutzerklärung beschrieben sind. Schlussendlich verwenden wir aktive Protokollierung und Alarmierung, integriert mit einem Kernel- Level-Audit-System, das uns bei anormalen Aktivitäten auf unseren Servern warnt. Diese Protokolle werden regelmäßig auf Aktivitäten überprüft, die auf eine Kompromittierung hinweisen könnten. Darüber hinaus führt eine ausbleibende Bestätigung von Audit-Log-Nachrichten zu einem selbstständigen Überwachungs-Alarm. Fazit Die Menschen hinter StartMail verfügen über langjährige Erfahrung mit Dienstleistungen für mehr Privatsphäre. Unser Ziel war es, einen -Service zu schaffen, der das Versprechen Verschlüsselung leicht gemacht wirklich hält und Menschen hilft, Ihr Recht auf sichere und private Kommunikation wiederzuerlangen. Eine Plattform zu schaffen, die verschlüsselte - Kommunikation für durchschnittliche Anwender ermöglicht, war ein Prozess, nach der optimalen Kombination aus Benutzerfreundlichkeit, Datenschutz und Sicherheit zu suchen. Wir verwenden bewährte Kryptographie-Bibliotheken und setzen auf Standard-Implementierung, um die zugrundeliegenden Sicherheitsstruktur zu schaffen. Unser Entwicklungsprozess ist zur Gänze auf die Beseitigung von Schwachstellen fokussiert, bevor sie unserer Codebasis hinzugefügt werden. Unser sehr strenger (und komplexer) Kontowiederherstellungsprozess verhindert, dass unser Personal die Fähigkeit hat, Konten zurückzusetzen. Eines der wichtigsten Merkmale von StartMail ist der persönliche Tresor der Nutzer, der uns erlaubt, alle dem Nutzer gehörenden Daten verschlüsselt zu speichern. Wir haben unsere Entscheidungen sorgfältig durchdacht, wie z. B. die Wahl der serverseitigen Kryptographie versus browserbasierten JavaScript-Lösungen. Wir haben sorgfältig erwogen, wo der private OpenPGP-Schlüssel gespeichert werden kann, um auch für technisch nicht versierte Anwender maximale Sicherheit zu gewährleisten. Wir haben die Verbesserung unserer Such- und Spamerkennungsalgorithmen gegen den Schutz der -Inhalte abgewogen und überlegt, ob wir den StartMail Source-Code freigeben sollen oder ob die Quelle geschlossen bleibt. In jedem Fall, in dem wir die Wahl hatten, entschieden wir uns und werden es immer tun für jene Alternative, die die Sicherheit und Privatsphäre unserer Nutzer begünstigt. Unsere Vorgehensweise bei der Einführung neuer Technologien in unser System ist sehr konservativ. Wir verlassen uns nur auf bewährte Lösungen, denen die kryptographische Gemeinschaft vertraut, die 18

19 Privatsphäre unserer Nutzer sicher zu schützen. Gleichzeitig haben wir ein wachsames Auge für neue Möglichkeiten, um unsere Sicherheitsmaßnahmen zu verbessern. In regelmäßigen Abständen bewerten wir unsere Entscheidungen im Hinblick auf neue verfügbare Technologien, um auch weiterhin den sichersten und modernsten Service zu bieten. Literaturhinweise 1: "StartMail Privacy Policy 2: "Graceful Degradation" 3: "OpenBSD contributors list" 4: "Why shouldn't we roll our own?" 5: "LibreSSL - Te frst 30 days" 6: "Startmail Qualys SSL Labs report" 7: "PGP Encryption" 8: "RFC 4880" 9: "MIT PGP Public Key Server" 10: "Linux Unifed Key Setup" 19