StartMail Technisches White Paper

StartMail Technisches White Paper
Eigentümer
Version
Datum
Alex van Eesteren – [email protected]
1.0.3
13.08.2014
Inhaltsverzeichnis
Vorwort …………………………………………………………………………………………….3
Überblick über StartMail …...……………………………………………………………………..3
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
Vorwort
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 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 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-MailKommunikation.
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 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 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 E-Mails zuzugreifen. Standardmäßig bietet StartMail jedoch die folgenden Sicherheitsfunktionen
für Nutzerinnen:
 Asymmetrische Verschlüsselung und Signatur mit OpenPGP – sowohl für StartMailNutzerinnen als auch für Nicht-StartMail-Nutzerinnen
3





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 E-Mail, Präferenzen und Anti Spam
Profilen, werden im „User-Tresor“ verschlüsselt gespeichert
Eingehende E-Mails 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 E-Mail-Nutzer daran gewöhnt, über
einen Browser auf ihre E-Mails zuzugreifen. Zweitens, da die Nutzer 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.
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 OpenPGPOperationen 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:
http://www.matasano.com/articles/javascript-cryptography/
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

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 JavaScriptCodes 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 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üsselVerwaltung 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
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 EMails 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 E-Mails 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 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 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 WebmailService 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
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
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 SourceBibliotheken, 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



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 (AESGCM 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 ist gegenwärtig dabei, seine Zertifikate auf SwissSign, einen Schweizer Zertifizierer im
Besitz der Schweizerischen Post (einer Regierungsorganisation), umzustellen. Ein 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 EMails 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 E-Mail-Provider sich nicht dem
Datenschutz und der Sicherheit verschrieben haben und wenn Nutzer ihre Mails über IMAP abrufen
(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.
9
10
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 E-Mails haben wir folgende Maßnahmen ergriffen:


Verschleierung lokaler IP-Adressen und Hostnamen. Dies machen wir, um keine
Informationen über die Infrastruktur preiszugeben.
Zurückweisen von E-Mails, die von gesperrten Absenderadressen kommen. Zum Beispiel EMails die angeblich von [email protected] oder ähnlichen Adressen eingehen.
Speziell für ausgehende E-Mails befreien wir die Header von folgenden Informationen:







User-Agent
X-Mailer
Ursprungs-IP
X-Enigmail-Version
X-Virus-Scanned
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 E-Mails der Nutzer und alle privaten Angaben zum Nutzerkonto im eigenen UserTresor 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 UserTresor öffnen muss.
11
E-Mail
E-Mails 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 UserTresor 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 E-Mails
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 EMails 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 E-Maildienste 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
Das Senden einer F&A-Nachricht ist dem Senden einer verschlüsselten E-Mail 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 E-Mail verschickt. Stattdessen:






Wird sie verschlüsselt auf unseren Servern aufbewahrt.
Eine Benachrichtigungs-E-Mail 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 StandardProtokoll, 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
Wir verwenden das Standard-GnuPG-Tool, um neue Schlüsselpaare (privat und öffentlich) auf
unseren Servern zu generieren. Die E-Mail-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 E-Mail-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 E-Mail 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
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 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 garantiert ist, 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-MailSignaturen 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 E-Mail-Adresse
Bei der Anmeldung können die Nutzer zwischen dem Beziehen eines Wiederherstellungs-Codes und
dem Einrichten einer Wiederherstellungs E-Mail-Adresse wählen. Der Wiederherstellungs-Code wird
nur angeboten, wenn der User keine Wiederherstellungs E-Mail-Adresse wählt. Wir entwickeln neue
Funktionen, um auch jenen Nutzern einen Wiederherstellungs-Code anbieten zu können, die eine
Wiederherstellungs E-Mail-Adresse angegeben haben. Der Code kann als Backup nützlich sein, falls
der Zugriff auf die Wiederherstellungs E-Mail-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 E-Mail-Adresse angegeben hat,
wird StartMail den Code nicht speichern: Der Nutzer selbst ist für die Aufbewahrung voll
verantwortlich. Falls der Nutzer eine Wiederherstellungs E-Mail-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 E-MailAdressen 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
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 E-Mail-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üfungsE-Mail an die Wiederherstellungs-Adresse gesendet. Es ist sehr wichtig, diese E-Mail zu bestätigen,
da dieser Schritt StartMail erlaubt, das Besitzrecht an der E-Mail-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 E-Mail-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
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 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 Nutzer verwenden für den Zugriff auf Ihre E-Mails von einem separaten EMail-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 E-Mails 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 IMAPFä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
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 KernelLevel-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 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-MailKommunikation 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 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 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
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: https://www.startmail.com/privacy "StartMail Privacy Policy“
2: http://en.wikipedia.org/wiki/Graceful_degradation "Graceful Degradation"
3: http://www.openbsdfoundation.org/contributors.html "OpenBSD contributors list"
4: http://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-own "Why shouldn't
we roll our own?"
5: http://www.openbsd.org/papers/bsdcan14-libressl/ "LibreSSL - Te frst 30 days"
6: https://www.ssllabs.com/ssltest/analyze.html?d=startmail.com "Startmail Qualys SSL Labs report"
7: http://en.wikipedia.org/wiki/Pretty_Good_Privacy "PGP Encryption"
8: http://tools.ietf.org/html/rfc4880 "RFC 4880"
9: https://pgp.mit.edu/ "MIT PGP Public Key Server"
10: https://en.wikipedia.org/wiki/Linux_Unifed_Key_Setup "Linux Unifed Key Setup"
19