Technisches White Paper
Inhaltsverzeichnis
Konstruktionserwägungen.
3.1 Webmail vs. Desktop-Client.
3.2 Clientseitige vs. Serverseitige Verschlüsselung.
3.3 Clientseitige vs. serverseitige Schlüsselspeicherung.
3.4 Leistung und Information zu Fehlerbehebung vs. Datenschutz.
3.5 Open Source vs Closed Source Software.Sicherheitsmaßnahmen.
4.1 Prozesse und Grundsätze.
4.1.1 Entwicklungsprozess.
4.1.2 Open Source.
4.1.3 Kryptographie.
4.2 Servicearchitektur.
4.2.1 Allgemeine Architektur.
4.2.2 User-Tresor.
4.2.3 Webmail-Features.
4.2.4 Wiederherstellung.
4.2.5 IMAP und mobile Geräte.
4.2.6 Infrastruktursicherheit.
1. Einleitung
In den letzten Jahren – insbesondere im Jahr 2013 – haben uns zahlreiche Ereignisse gezeigt, dass unsere Alltagskommunikation für Lauscher äußerst wertvoll ist. E-Mails gehören zu den heikelsten Services in puncto Datenschutz, die User 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 User 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 durchschnittlichen User 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 E-Mail-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 E-Mail-Kommunikation.
Dieses Dokument erläutert die von uns getroffenen Entscheidungen in Bezug auf Sicherheitspraktiken und den Privatsphäre-Schutz unserer User. 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.
2. Überblick über StartMail
StartMail ist eine Plattform für sichere E-Mail-Kommunikation. Auf unseren Service kann sowohl von einem Web-Interface aus zugegriffen werden als auch über das traditionelle IMAP-Protokoll, das mit bestehenden E-Mail-Clients kompatibel ist.
Versierte Anwender mit ausreichend Wissen und Erfahrung können von der erweiterten Funktionalität profitieren: Zum Beispiel bietet StartMail diesen Usern die Möglichkeit, ihren Wiederherstellungscode selbstständig zu speichern, ihren bestehenden OpenPGP-Schlüssel zu importieren und zu verwalten oder auch alle OpenPGP-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 User haben die Möglichkeit, auf alle Kryptographie bezogenen Funktionen zu verzichten und ihre Kryptographie eigenständig zu behandeln und dann über IMAP auf ihre E-Mails zuzugreifen. Standardmäßig bietet StartMail jedoch die folgenden Sicherheitsfunktionen für User:
- Asymmetrische Verschlüsselung und Signatur mit OpenPGP – sowohl für StartMail-User als auch für Nicht-StartMail-User.
- Passwortbasierte Verschlüsselung für User, die kein PGP verwenden.
- Operative Gesellschaft und Rechtsträger strikt außerhalb der US-Gerichtsbarkeit.
- Minimale Datenspeicherung über User und Verzicht auf Tracking-Cookies, wie in unseren sehr strengen Datenschutzrichtlinien [1] beschrieben.
- Alle Daten im Besitz des Users, einschließlich E-Mails, Präferenzen und Anti-Spam-Profile werden im “User-Tresor” verschlüsselt gespeichert.
- Eingehende E-Mails für User werden augenblicklich für die spätere Zustellung , wenn der User seinen User-Tresor öffnet, mithilfe des öffentlichen Schlüssel des “Queue-Schlüsselpaars” verschlüsselt.
3. Konstruktionserwägungen
Während der Entwicklung von StartMail wurden wir vor mehrere Herausforderungen in Bezug auf Sicherheit, Datenschutz und Userfreundlichkeit gestellt. In diesem Abschnitt werden wir die relevantesten Entscheidungen behandeln.
3.1. 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 E-Mail-User daran gewöhnt, über einen Browser auf ihre E-Mails zuzugreifen. Zweitens, da die User erwarten, von verschiedenen Geräten aus auf Ihre E-Mails 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 E-Mail-Clients, die mit IMAP funktionieren.
3.2. 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. Eine Reihe von zwingenden Gründen, warum dies der Fall ist, beschreibt die NCC Group in diesem ausgezeichneten Artikel:
Zu den Gründen, clientseitige kryptographische Operationen abzulehnen, zählen:
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 Usern 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 E-Mail-Anbieter Zugang zum privaten OpenPGP-Schlüssel des Users hat, was das benötigte Vertrauen des Users in den E-Mail-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 bieten.
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.
3.3. 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 Browser. Was in anderen Zusammenhängen mit “graceful degradation” [2] gelöst werden könnte (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 entschieden 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. Viele User 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.
3.4. Leistung und Information zu 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 User.
Ein essenzielles 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 User als Spam ansehen und was nicht. Wir haben uns entschieden, diese Informationen im persönlichen Tresor des Users 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 User dem ganzen System zur Verfügung stünden, was unsere Verpflichtung, dem Datenschutz oberste Priorität einzuräumen, verletzen würde.
Eine ähnliche Situation besteht bei der Suchindexierung. Damit die Suchfunktion schnell reagieren kann, müssen E-Mails indexiert werden und die Indizes müssen aktuell sein. Dies kann zu jedem Zeitpunkt geschehen, vorausgesetzt es geschieht bereits, bevor der User eine Suche startet. Im Falle von StartMail können die Suchindizes nur aktualisiert werden, wenn der User eingeloggt ist. Ist er nicht eingeloggt, sind E-Mails und Indizes verschlüsselt im User-Tresor gespeichert und die Indexierungsoperationen können nicht stattfinden. Diese Einschränkung, die uns zur Indexierung von E-Mails ausschließlich nach dem Login beschränkt, bietet für unsere User bessere Privatsphäre und Sicherheit, während sie nur einen kleinen Nachteil in der Funktionalität mit sich bringt.
3.5. Open Source vs Closed Source Software
Der StartMail 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ßen 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.
Aus diesem Grund haben wir uns aus Sicherheitsgründen entschlossen, 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.
4. Sicherheitsmaßnahmen
Im vorherigen 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.
4.1. Prozesse und Grundsätze
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.
4.1.1. Entwicklungsprozess
Ein sicherer Code ist eine Top-Priorität bei einem Projekt wie StartMail. Natürlich existieren diverse Maßnahmen, um die Folgen potentieller Schwachstellen in unserer Software zu schmälern.
Wir haben zahlreiche Maßnahmen etabliert, um sicherzustellen, dass interne und externe Prüfer eine objektive Einschätzung des StartMail-Codes vornehmen 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.
4.1.2. 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 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].
4.1.3. Kryptographie
Das Rad in Sachen Kryptographie (und Sicherheit im Allgemeinen) neu zu erfinden, ist immer eine sehr schlechte Idee [4]. Es ist nicht bloß unnötig, sondern auch potentiell gefährlich. Die Geschichte zeigt, dass man in der Kryptographie 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 Kryptographie-Experten überlassen, stechen diese Kategorien am deutlichsten hervor:
- Kryptographie-Algorithmen für Verschlüsselung, Entschlüsselung und Hashing. Es ist keine besonders gute Idee zu versuchen, AES, RSA oder SHA-2 zu ersetzen.
- Kryptographische Protokolle wie PBKDF2, HMAC, SSL, und diverse PKCS-Standards. Selbst beim Verwenden bewährter kryptographischer Algorithmen ist es normalerweise unklug, neue Schemata einzubringen.
- Kryptographische Implementierungen. Auch, wenn man Gebrauch von kryptographischen 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-Commuity [5] geschenkt wurde, verfolgen wir die Entwicklungen genau und ziehen in Betracht, OpenSSL so bald wie möglich durch einen geeigneten Ersatz abzulösen.
4.2. Servicearchitektur
Der vorherige Abschnitt widmet sich den Sicherheitsmaßnahmen auf organisatorischer Ebene und der Prozessebene. In diesem Abschnitt erklären wir unsere Überlegungen in Bezug auf die generelle Architektur, Webmail, Kontowiederherstellungs-Methoden und IMAP.
4.2.1. Allgemeine Architektur
4.2.1.1. Transport Layer Security (TLS)
Um mit unseren Usern sicher kommunizieren zu können, verschlüsseln wir jede Verbindung mittels TLS-Protokoll. Die genauen Details der Verschlüsselung einer Verbindung zu StartMail hängen davon ab, worauf sich Server und Client während der Einrichtung der TLS-Verbindung einigen. Durch die Konfiguration von sicheren Präferenzen haben die Clients, die diese Anforderungen unterstützen (also alle aktuellen Clients), sichere Verbindungen zu uns.
StartMail implementiert weitreichende Sicherheitsmaßnahmen in Zusammenhang mit TLS:
- Unser Server sind entsprechend den aktuellen Standards konfiguriert.
- Wir nutzen Zertifikate von Let’s Encrypt, der größten Zertifizierungsstelle (Certificate Authority, CA) der Welt und transparente Non-Profit-Organisation, deren Mission es ist, das Internet sicherer zu machen und die Privatsphäre der Internetnutzer zu schützen.
- Wir nutzen CAA DNS Records, um zu unterbinden, dass andere CAs Zertifikate für StartMail-Domains ausstellen.
- Wir überwachen die Zertifikatstransparenz-Logs auf die Ausstellung von Zertifikaten für StartMail-Domains.
- Wir nutzen DNSSEC, um DNS-Einträge zu signieren, wodurch Besucher mit aktiver Domain-Signaturüberprüfung vor manipulierten DNS-Antworten geschützt werden.
- Wir nutzen HTTP Strict Transport Security (HSTS). Unsere Domain wurde an die HSTS Preload List übermittelt.
- Wir fördern die Nutzung von Perfect Forward Secrecy (PFS), die vermeidet, dass vergangener Datenverkehr entschlüsselt werden kann – auch in dem unwahrscheinlichen Fall, dass unser privater Schlüssel kompromittiert wird.
- Wir verbessern Datenschutz und Sicherheit für unsere Nutzer durch aktivierte Anheftung des Online Certificate Status Protocol (OCSP).
- Wir nutzen DANE (TLSA DNS Records) für die Veröffentlichung der Fingerprints von TLS-Zertifikaten, die von unseren E-Mail-Übermittlungssystemen (SMTP) genutzt wird, wodurch Dritte sicherstellen können, dass sie mit unseren MX-Servern kommunizieren. Wenn E-Mails an Dritte gesendet werden, überprüfen wir deren DANE-Einträge, um die authentifizierte und verschlüsselte Zustellung zu gewährleisten.
- Dementsprechend nutzen wir MTA-STS, um Gültigkeitsüberprüfungen der Zertifikate für eingehende Mails zu erzwingen.
Eine vollständige Übersicht unserer TLS-Verbindung und -Praktiken finden Sie in unserem SSL Labs report [6].
4.2.1.2. Verschlüsselung bei Übermittlung 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 über weniger seriöse externe Anbieter geliefert werden können. OpenPGP ist besonders wichtig für die Kommunikation mit anderen, deren E-Mail-Anbieter sich nicht dem Datenschutz und der Sicherheit verschrieben haben und wenn User via IMAP auf ihre E-Mails zugreifen (und dementsprechend Kopien ihrer E-Mails 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.
4.2.1.3. Header Stripping
Als weiteres Datenschutz-Feature haben wir einige Header-Stripping-Funktionen für eingehende und ausgehende E-Mails hinzugefügt.
Sowohl für ein- als auch für ausgehende E-Mails haben wir folgende Maßnahmen ergriffen:
- Verschleierung lokaler IP-Adressen und Hostnamen. Dies geschieht, damit keine Informationen über die Infrastruktur preisgegeben wird.
- Zurückweisen von E-Mails, die von gesperrten Absenderadressen kommen. Zum Beispiel E-Mails die angeblich von administrator@startmail.com oder ähnlichen Adressen eingehen.
Speziell für ausgehende E-Mails befreien wir die Header von folgenden Informationen:
- Mime-Version
- Received
- User-Agent
- X-Enigmail-Version
- X-Mailer
- X-Originating-IP
- X-Pgp-Agent
- X-Virus-Scanned
4.2.1.4. Ratenbegrenzung
Wir haben Ratenbegrenzungs-Features etabliert, um das System vor Passwort brute-forcing (Ausprobieren verschiedener Passwörter) und username enumeration (Aufzählen von Usernamen) 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 in Übereinstimmung mit unserer Datenschutzerklärung.
4.2.2. User-Tresor
Userdaten werden in sogenannten User-Tresoren gespeichert, die im Grunde nichts anderes sind als komplett verschlüsselte LUKS volume [7]. Nachdem User ihr Kontopasswort 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 keine Passwörter unserer User speichern. 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.
4.2.2.1. Was speichern wir in User-Tresoren?
Wir speichern die E-Mails der User und alle privaten Angaben zum Userkonto im eigenen User-Tresor des Users (Details finden Sie in unseren Datenschutzrichtlinien). Das bedeutet, dass jedes Mal, wenn ein User auf seinen Posteingang zugreifen will, er erst den Account, also seinen User-Tresor öffnen muss.
4.2.2.1.1 E-Mail
E-Mails werden im User-Tresor gelagert, sobald sie an einen Account zugestellt wurden. Natürlich können Nachrichten, die eingehen, während der User ausgeloggt ist, nicht zugestellt werden, ehe er seinen User-Tresor manuell öffnet, indem er sich einloggt.
Da wir wollen, dass Daten nur für die rechtmäßigen Eigentümer zugänglich sind, wird ein zusätzliches OpenPGP-Schlüsselpaar für jeden User 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 User eintrifft, wird diese mithilfe seines queue’s public key verschlüsselt und in einer Warteschleife gespeichert. Sobald der Tresor geöffnet wird (durch das Einloggen des Users), werden diese Mails vom queue’s private key entschlüsselt und in den Posteingang des Users verschoben.
HINWEIS: Das Queue-Schlüsselpaar ist *vollkommen getrennt* vom OpenPGP-Schlüsselpaar des Accounts, das für die Kommunikation verwendet wird.
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 Sicherheitsebene.
4.2.2.1.2 Spam und Metadaten
StartMail ermöglicht den Usern, ihren bayesschen Spam-Filter zu trainieren, indem sie E-Mails im Webmail-Interface als Spam oder Nicht-Spam markieren. Die mit dem Spamfilter-Training verbundenen Metadaten werden als sensible Userdaten betrachtet, da sie zumindest einen Teil der Inhalte der E-Mails eines Users enthalten. Aus diesem Grund werden diese Daten im User-Tresor aufbewahrt. Das bedeutet, dass niemand außer dem User Zugriff auf diese Daten hat und dass jeder User seinen eigenen, persönlich trainierten Spam-Filter hat.
4.2.2.1.3 Schlüsselbund
Wenn sich User 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 andere (öffentliche wie private) Schlüssel für die Kommunikation mit anderen Usern zu ihrem Schlüsselbund hinzufügen.
4.2.3. Webmail-Features
Wir bieten über unsere Webmail-Plattform verschiedene Features an, die die Sicherheit von Nachrichten erhöhen. In diesem Kapitel zeigen wir Details über die Implementierung dieser Features auf.
4.2.3.1. Passwortgeschützte Nachrichten
Nachrichten werden mit einem Passwort verschlüsselt, indem vor dem Versenden einer E-Mail „Verschlüsseln“ aktiviert wird. Passwortgeschützte Nachrichten sind bis auf wenige Ausnahmen verschlüsselten E-Mails sehr ähnlich:
Die Nachricht wird mit GnuPG im symmetrischen Modus verschlüsselt, wobei das Passwort die an GnuPG gelieferte Passphrase ist.
Im Gegensatz zu einer klassischen, asymmetrisch OpenPGP-verschlüsselten Nachricht, die für alle öffentlichen Schlüssel der Empfänger verschlüsselt werden muss, ist diese Verschlüsselungs-Option für jegliche Empfänger verfügbar – selbst jene, die keinen öffentlichen OpenPGP-Schlüssel importiert haben.
Die Nachricht wird nicht in einer E-Mail versendet, stattdessen
- Wird sie verschlüsselt auf unseren Servern gespeichert.
- Der Empfänger erhält eine Benachrichtigungs-E-Mail. Diese Mitteilung beinhaltet einen Link zu einem StartMail-Server.
- Wenn der Empfänger auf den Link in der Benachrichtigungs-Mail klickt, muss das Passwort eingegeben werden, um die E-Mail zu entschlüsseln.
- Der Empfänger hat 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 Nachricht einzusehen und – auf sicherem Wege – über dasselbe Interface eine Antwort zu senden.
Als zusätzliche Sicherheitsmaßnahme werden Nachrichten nach einer bestimmten Zeitspanne automatisch von den StartMail-Servern gelöscht.
4.2.3.2. OpenPGP
Wir bieten OpenPGP functionality [8] in unserem Webmail-Interface an. OpenPGP ist ein Standard-Protokoll, näher beschrieben in RFC 4880 [9]. Laut dem OpenPGP-Standard werden zwei separate Schlüssel für das Ver- und Entschlüsseln von Daten verwendet. Jeder User 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 zur Weitergabe an andere entwickelt wurde. Nachrichten mit einem speziellen öffentlichen Schlüssel können ausschließlich mit dem dazugehörenden privaten Schlüssel entschlüsselt werden.
Sobald User ihre OpenPGP-Funktionen aktivieren, werden sie dazu aufgefordert, entweder ein neues Schlüsselpaar zu generieren oder ein bereits bestehendes zu importieren.
4.2.3.2.1 Neue OpenPGP-Schlüssel
Wir verwenden das Standard-GnuPG-Tool, um ein neues Schlüsselpaar (einen privaten und einen öffentlichen Schlüssel) auf unseren Servern zu generieren. Die dem Schlüsselpaar zugeordnete E-Mail-Adresse ist selbstverständlich die StartMail-Adresse des Users.
Die generierten Schlüssel sind 4096-bit RSA-Schlüssel.
4.2.3.2.2 Importierte OpenPGP-Schlüssel
User, die bereits ein OpenPGP-Schlüsselpaar besitzen, können dieses in StartMail importieren. Die StartMail-Adresse muss dem Schlüsselpaar vor dem Import zugeordnet werden.
4.2.3.2.3 OpenPGP Schlüssel-Management
Das grundlegende Schlüssel-Management ist in der Web-Anwendung von StartMail verfügbar:
- Ändern der Passphrase des privaten Schlüssels
- Schlüssel importieren/exportieren
- Schlüssel neu generieren
4.2.3.2.4 Passphrasen zwischenspeichern
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 User zur Eingabe aufgefordert und können optional wählen, dass sie für die Dauer der Sitzung nicht mehr eingegeben werden muss.
Wenn die Zwischenspeicherung-Option gewählt wird, wird die Passphrase verschlüsselt und in-memory auf dem Server gespeichert. Der Verschlüsselungs-Schlüssel für die Passphrase ist in einem Browser-Cookie gespeichert. Das bedeutet, dass ein Angreifer, der Zugriff auf die Cookies eines Users gewinnt, die Passphrase selbst trotzdem nicht wiederherstellen kann.
Natürlich ist die sicherste – wenn auch etwas umständliche – Option, die Passphrase überhaupt nicht zwischenzuspeichern. Aber diese Entscheidung überlassen wir unseren Usern.
4.2.3.2.5 OpenPGP Key Directory
Wenn User ihre OpenPGP-Operationen von StartMail abwickeln lassen, wird der öffentliche Schlüssel automatisch in ein internes Schlüsselverzeichnis aufgenommen. Wenn der User eine verschlüsselte E-Mail an einen anderen StartMail-Userverstellt, der ebenfalls OpenPGP in StartMail eingerichtet hat, wird der öffentliche Schlüssel des Empfängers aus dem Schlüsselverzeichnis abgerufen. User können sich in ihren Einstellungen aus diesem Schlüsselverzeichnis abmelden.
HINWEIS: Die öffentlichen Schlüssel werden weder mit StartMail-Usern geteilt, noch sind sie öffentlich zugänglich. Sie werden nur verwendet, um die Kommunikation von StartMail-Usern *untereinander* transparent zu verschlüsseln. Die User haben jedoch die Möglichkeit, ihre öffentlichen OpenPGP-Schlüssel auf den MIT OpenPGP Key Server [10] hochzuladen.
4.2.3.2.6 Signieren und Verifizieren einer Signatur
Zusammen mit E-Mail-Verschlüsselung und Entschlüsselung bieten wir im StartMail Web-Interface die Möglichkeit, E-Mails mit OpenPGP Signaturen zu signieren. Das Signieren von E-Mails ist sehr wichtig: Es erlaubt, die Identität des Absenders zu überprüfen, indem es sicherstellt, dass der Absender der verschlüsselten E-Mail der Eigentümer des privaten Schlüssels ist, der mit seiner E-Mail-Adresse übereinstimmt. Standardmäßig werden auch alle über das StartMail Web-Interface versendeten OpenPGP-verschlüsselten E-Mails signiert.
Das StartMail Web-Interface liefert die visuelle Rückmeldung über die Gültigkeit der E-Mail-Signaturen und warnt User, wenn sich Nachrichten mit einer ungültigen Signatur erhalten. Um die Signaturen anderer StartMail-User zu überprüfen, wird deren öffentlicher OpenPGP-Schlüssel automatisch von dem im vorigen Abschnitt erwähnten Schlüsselverzeichnis abgerufen.
4.2.3.2.7 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 Users und alle anderen Schlüssel, die er hochgeladen oder importiert hat.
4.2.3.2.8 OpenPGP und BCC-Empfänger
Mit traditionell PGP-verschlüsselten E-Mails ist die Verwendung des BCC-Feldes, um Empfänger zu deklarieren, die anderen verborgen bleiben sollen, nicht möglich. Dies erklärt sich aus der Tatsache, dass eine verschlüsselte Nachricht auch die Schlüssel-ID enthält, für die die Nachricht verschlüsselt wurde. Jeder Empfänger, der von der Schlüssel-ID weiß, kann herausfinden, wer in die Nachricht inkludiert ist, indem er die gelisteten Schlüssel in der verschlüsselten Nachricht untersucht.
Es gibt mehrere Möglichkeiten, diesen Datenlecks vorzubeugen. Wir haben uns entschieden, alle BCC-Empfänger von einer Nachricht zu entfernen, die über unseren Webmail-Service gesendet wird. Anschließend erstellen und verschlüsseln wir eine separate E-Mail für jeden individuellen BCC-Empfänger und nehmen sie vollständig aus der gesendeten Original-Nachricht aus. Auf diese Art sickern keinerlei Informationen über die BCC-Empfänger an die anderen Haupt-Empfänger durch.
4.2.3.2.9 PGP-Nachricht-Arten (MIME/Inline)
Wir übernehmen vollständig die PGP/MIME-Nachrichtenstruktur bei allen ausgehenden Nachrichten, da dies alle Dateianhänge sauber verschlüsselt, ohne Metadaten über sie preiszugeben. Außerdem ist es zuverlässiger bei Nicht-ASCII-Text und funktioniert ordnungsgemäß mit HTML-E-Mail.
Schlussendlich wird PGP/MIME generell als die am besten geeignete Methode betrachtet und ermöglicht allen E-Mail-Clients, die Nachricht ordnungsgemäß anzuzeigen, unabhängig davon, ob sie PGP unterstützen oder nicht.
Wenn wir eine Nachricht empfangen, die mit PGP/Inline verschlüsselt oder signiert wurde, können wir sie korrekt entschlüsseln (sofern wir Zugriff auf den zugehörigen privaten Schlüssel haben) und Signaturen verifizieren (sofern wir Zugriff auf den öffentlichen Schlüssel haben). Wenn wir PGP/Inline-Antworten beantworten oder weiterleiten, konvertieren wir sie in PGP/MIME.
Obwohl PGP/MIME dafür bekannt ist, von einigen älteren E-Mail-Clients nicht unterstützt zu werden, legen wir Wert auf die Datenschutz- und Sicherheitsverbesserungen dieser Struktur und erachten diese als wichtiger als die Kompatibilität mit Clients, deren MIME-Kompatibilität eingeschränkt ist.
4.2.4. Wiederherstellung
4.2.4.1. Passwort-Wiederherstellung für Persönliche Konten
Sollten User jemals die Passphrase ihres Accounts vergessen, bieten wir zwei Möglichkeiten, sie wiederherzustellen:
- Mit einem Wiederherstellungs-Code
- Mit einem Link zum Zurücksetzen an die Wiederherstellungs-E-Mail-Adresse
Bei der Anmeldung können die User zwischen dem Beziehen eines Wiederherstellungs-Codes und dem Einrichten einer Wiederherstellungs-E-Mail-Adresse wählen. Der Wiederherstellungs-Code wird angeboten, wenn sich der User entscheidet, keine Wiederherstellungs-E-Mail-Adresse zu wählen und zu bestätigen.
Es ist wichtig zu beachten, dass – unabhängig von der Wahl des Users – automatisch ein Code durch das System generiert wird. Der User ist komplett verantwortlich für dessen sichere Verwahrung. Wenn der User keine Wiederherstellungs-E-Mail-Adresse angibt und bestätigt, wird StartMail den Code nicht speichern. Wenn der User eine Wiederherstellungs-E-Mail-Adresse angibt und bestätigt, speichert StartMail den Code verschlüsselt. Wir erläutern diesen Prozess in diesem Abschnitt genau.
4.2.4.1.1 Wiederherstellung mit einem Wiederherstellungs-Code
Der bei der Anmeldung erhaltene Wiederherstellungscode kann verwendet werden, um das Konto manuell zurückzusetzen, falls der User sein Konto-Passwort vergisst.
StartMail speichert keine Wiederherstellungscodes für Konten, die keine Wiederherstellungs-E-Mail-Adressen festgelegt haben. Aus diesem Grund können unsere Mitarbeiter Usern nicht weiterhelfen, wenn sie ihren Wiederherstellungscode verloren haben. Es ist uns technisch nicht möglich, Konten manuell 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 eine Wiederherstellung gebeten haben.
Einen Wiederherstellungscode auf diese Weise herauszugeben würde bedeutet, dass sich die Verantwortung für sichere Speicherung zum User hin verschiebt. Wir empfehlen, dass technisch weniger versierte Anwender, die eventuell Schwierigkeiten beim sicheren Speichern des Wiederherstellungscodes haben könnten, eine Wiederherstellungs E-Mail-Adresse angeben und StartMail das Speichern und Wiederherstellen für sie erledigen lassen, falls dies nötig sein sollte.
4.2.4.1.2 Wiederherstellung mit einer Wiederherstellungs-Adresse
Addressprüfung
Nach der Anmeldung und dem Festlegen einer Wiederherstellungs-Adresse wird eine Überprüfungs-E-Mail an die Wiederherstellungs-Adresse gesendet. Es ist sehr wichtig, diese E-Mail zu bestätigen, da dieser Schritt StartMail erlaubt, das Eigentumsrecht an der E-Mail-Adresse zu prüfen, die zur Wiederherstellung angegeben wurde. Sobald die Adresse geprüft ist, kann der User damit das Zurücksetzen beantragen, falls nötig.
HINWEIS: Die User 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 Wiederherstellungs-Codes
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, eine Anfrage zu genehmigen. Sollte die Autorität einer Person kompromittiert werden, ist für die Kontowiederherstellung immer eine zusätzliche Interaktion erforderlich.
Sobald der zweite Manager die Wiederherstellungsanfrage anerkannt und das Wiederherstellungsfile mit seinem Schlüssel entschlüsselt hat, wird die daraus resultierende Datei an das StartMail System weitergeleitet, das für die Entfernung der letzten Verschlüsselungsschicht verantwortlich ist und den Wiederherstellungscode an die bestätigte Wiederherstellungs-Adresse versendet.
4.2.4.2. Kontowiederherstellung
Der Kontowiederherstellungs-Prozess erfordert die Passwortänderung eines User-Tresors. Der Tresor ist ein LUKS volume [7] mit mehreren Schlüssel-Slots: Ein Slot wird für die Authentifizierung verwendet, ein anderer für die Wiederherstellung. Eine erfolgreiche Wiederherstellung führt zu folgendem Ergebnis:
- Der Tresor wird mit dem Schlüssel, der dem Wiederherstellungs-Slot entspricht, aufgesperrt
- Der alte Authentifizierungs-Slot wird durch Eingabe eines neuen Passwortes überschrieben
- Der alte Wiederherstellungs-Slot wird überschrieben, indem ein neuer Wiederherstellungscode generiert wird.
4.2.5. IMAP und mobile Geräte
User, die über einen separaten E-Mail-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 User greifen über einen separaten E-Mail-Client auf ihre E-Mails zu und sind an das POP3-Protokoll gewöhnt. IMAP funktioniert auf eine sehr ähnliche Weise, ist aber so konzipiert, dass es Nachrichten so lange auf dem Remote-Server speichert, bis sie gelöscht werden, statt sie immer auf den Client-Rechner herunterzuladen und vom Server zu löschen.
IMAP (im Gegensatz zu POP3) gliedert sich natürlicher in die E-Mail-Ansicht im StartMail-Webinterface ein und ermöglicht es den Usern, dennoch von der sicheren Speicherung zu profitieren, die das User-Tresor-System bietet.
Wir empfehlen, jedes externe Gerät, das sich via IMAP mit StartMail verbindet, separate zu konfigurieren. Sobald User ein (benanntes) Gerät hinzufügen, erhalten sie eine spezifische Kombination aus Username, Passwort und IMAP-Serverinformationen, mit denen das Gerät konfiguriert werden kann.
Das Erstellen von separaten IMAP-Anmeldeinformationen für jedes Gerät bietet 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 die Nachrichten des Users. 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 verloren oder veraltet sein oder nicht mehr verwendet werden, ist es einfach, das Gerät zu entfernen und den Zugriff zu entziehen.
4.2.5.1. Automatisches Deaktivieren eines Gerätes
Nach mehreren erfolglosen Authentifizierungsversuchen wird der IMAP-Zugriff auf ein Gerät deaktiviert. User 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.
Sobald ein Gerät deaktiviert wurde, kann es nicht erneut aktiviert werden. Ein deaktiviertes Gerät kann der User als „neues“ Gerät wieder hinzugefügt werden.
4.2.6. 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.
5. Fazit
Die Menschen hinter StartMail verfügen über langjährige Erfahrung mit datenschutzfreundlichen Dienstleistungen. Unser Ziel war es, einen E-Mail-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 E-Mail-Kommunikation für durchschnittliche Anwender ermöglicht, war ein Prozess, nach der optimalen Kombination aus Userfreundlichkeit, 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 Features von StartMail ist der persönliche User-Tresor, der uns erlaubt, alle dem User 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 E-Mail-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 User bevorzugt.
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 Privatsphäre unserer User 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.
6. Literaturhinweise
https://www.startmail.com/de/datenschutz/ “StartMail Datenschutz”
https://en.wikipedia.org/wiki/Fault_tolerance “Fault tolerance” (Graceful degradation is a particular type of implementing fault tolerance)
http://www.openbsdfoundation.org/contributors.html “OpenBSD contributors list”
https://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-own “Why shouldn’t we roll our own?”
http://www.openbsd.org/papers/bsdcan14-libressl/ “LibreSSL – The first 30 days”
https://www.ssllabs.com/ssltest/analyze.html?d=startmail.com “StartMail Qualys SSL Labs report”
https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup “Linux Unified Key Setup”
https://en.wikipedia.org/wiki/Pretty_Good_Privacy “PGP Encryption”
http://tools.ietf.org/html/rfc4880 “RFC 4880”
https://pgp.mit.edu/ “MIT PGP Public Key Server”