[{"data":1,"prerenderedAt":115},["ShallowReactive",2],{"cjbD12bdfp0fTJy_YHVljz_R_cSA0k8VX0Zh3nRtw6M":3,"_apollo:default":87},{"page":4,"blog":13},{"__typename":5,"title":6,"slug":7,"subtitle":8,"_seoMetaTags":9,"_allSlugLocales":74,"deal":13,"tapfiliateReferralCode":8,"tapfiliateTapS":8,"footerTheme":79,"seoStructuredData":13,"hideTopNavigation":80,"sections":81},"PageRecord","Technisches White Paper","whitepaper","",[10,14,18,21,25,28,31,35,39,43,46,50,54,58,62,66,70],{"__typename":11,"tag":12,"attributes":13,"content":6},"Tag","title",null,{"__typename":11,"tag":15,"attributes":16,"content":13},"meta",{"property":17,"content":6},"og:title",{"__typename":11,"tag":15,"attributes":19,"content":13},{"name":20,"content":6},"twitter:title",{"__typename":11,"tag":15,"attributes":22,"content":13},{"name":23,"content":24},"description","StartMail schützt Ihre Daten, Online-Aktivitäten und Privatsphäre mit modernsten Sicherheitstechnologien.",{"__typename":11,"tag":15,"attributes":26,"content":13},{"property":27,"content":24},"og:description",{"__typename":11,"tag":15,"attributes":29,"content":13},{"name":30,"content":24},"twitter:description",{"__typename":11,"tag":15,"attributes":32,"content":13},{"property":33,"content":34},"og:image","https://www.datocms-assets.com/47413/1628148351-logo-wide.jpg?auto=format&fit=max&w=1200",{"__typename":11,"tag":15,"attributes":36,"content":13},{"property":37,"content":38},"og:image:width","1000",{"__typename":11,"tag":15,"attributes":40,"content":13},{"property":41,"content":42},"og:image:height","500",{"__typename":11,"tag":15,"attributes":44,"content":13},{"name":45,"content":34},"twitter:image",{"__typename":11,"tag":15,"attributes":47,"content":13},{"property":48,"content":49},"og:locale","de",{"__typename":11,"tag":15,"attributes":51,"content":13},{"property":52,"content":53},"og:type","article",{"__typename":11,"tag":15,"attributes":55,"content":13},{"property":56,"content":57},"og:site_name","StartMail",{"__typename":11,"tag":15,"attributes":59,"content":13},{"property":60,"content":61},"article:modified_time","2025-06-11T12:11:11Z",{"__typename":11,"tag":15,"attributes":63,"content":13},{"property":64,"content":65},"article:publisher","https://www.facebook.com/startmail/",{"__typename":11,"tag":15,"attributes":67,"content":13},{"name":68,"content":69},"twitter:card","summary",{"__typename":11,"tag":15,"attributes":71,"content":13},{"name":72,"content":73},"twitter:site","@MyStartMail",[75,77],{"__typename":76,"locale":49,"value":7},"StringNonNullMultiLocaleField",{"__typename":76,"locale":78,"value":7},"en","light",false,[82,84],{"__typename":83,"centeredTitle":80,"subtitle":8,"title":8},"PageHeaderRecord",{"__typename":85,"requiredBody":86},"MarkdownSectionRecord","\u003Ch2>Inhaltsverzeichnis \u003Ca name=\"startmail-technisches-white-paper\">\u003C/a>\u003C/h2>\n\n\u003Col>\n\u003Cli>\u003Cp>\u003Ca href=\"#1-einleitung\">Einleitung.\u003C/a>\u003C/p>\u003C/li>\n\u003Cli>\u003Cp>\u003Ca href=\"#2-%C3%BCberblick-%C3%BCber-startmail\">Überblick über StartMail\u003C/a>\u003C/p>\u003C/li>\n\u003Cli>\u003Cp>\u003Ca href=\"#3-konstruktionserw%C3%A4gungen\">Konstruktionserwägungen.\u003C/a>\u003Cbr>\n3.1 \u003Ca href=\"#31-webmail-vs-desktop-client\">Webmail vs. Desktop-Client.\u003C/a>\u003Cbr>\n3.2 \u003Ca href=\"#32-clientseitige-vs-serverseitige-verschl%C3%BCsselung\">Clientseitige vs. Serverseitige Verschlüsselung.\u003C/a>\u003Cbr>\n3.3 \u003Ca href=\"#33-clientseitige-vs-serverseitige-schl%C3%BCsselspeicherung\">Clientseitige vs. serverseitige Schlüsselspeicherung.\u003C/a>\u003Cbr>\n3.4 \u003Ca href=\"#34-leistung-und-information-zu-fehlerbehebung-vs-datenschutz\">Leistung und Information zu Fehlerbehebung vs. Datenschutz.\u003C/a>\u003Cbr>\n3.5 \u003Ca href=\"#35-open-source-vs-closed-source-software\">Open Source vs Closed Source Software.\u003C/a>\u003C/p>\u003C/li>\n\u003Cli>\u003Cp>\u003Ca href=\"#4-sicherheitsma%C3%9Fnahmen\">Sicherheitsmaßnahmen.\u003C/a>\u003Cbr>\n4.1 \u003Ca href=\"#41-prozesse-und-grunds%C3%A4tze\">Prozesse und Grundsätze.\u003C/a>\u003Cbr>\n4.1.1 \u003Ca href=\"#id=%22411-entwicklungsprozess%22\">Entwicklungsprozess.\u003C/a>\u003Cbr>\n4.1.2 \u003Ca href=\"#412-open-source\">Open Source.\u003C/a>\u003Cbr>\n4.1.3 \u003Ca href=\"#413-kryptographie\">Kryptographie.\u003C/a>\u003Cbr>\n4.2 \u003Ca href=\"#42-servicearchitektur\">Servicearchitektur.\u003C/a>\u003Cbr>\n4.2.1 \u003Ca href=\"#421-allgemeine-architektur\">Allgemeine Architektur.\u003C/a>\u003Cbr>\n4.2.2 \u003Ca href=\"#422-user-tresor\">User-Tresor.\u003C/a>\u003Cbr>\n4.2.3 \u003Ca href=\"#423-webmail-features\">Webmail-Features.\u003C/a>\u003Cbr>\n4.2.4 \u003Ca href=\"#424-wiederherstellung\">Wiederherstellung.\u003C/a>\u003Cbr>\n4.2.5 \u003Ca href=\"#426-imap-und-mobile-ger%C3%A4te\">IMAP und mobile Geräte.\u003C/a>\u003Cbr>\n4.2.6 \u003Ca href=\"#427-infrastruktursicherheit\">Infrastruktursicherheit.\u003C/a>\u003C/p>\u003C/li>\n\u003Cli>\u003Cp>\u003Ca href=\"#5-fazit\">Fazit.\u003C/a>\u003C/p>\u003C/li>\n\u003Cli>\u003Cp>\u003Ca href=\"#6-literaturhinweise\">Literaturhinweise.\u003C/a>\u003C/p>\u003C/li>\n\u003C/ol>\n\n\u003Ch2>1. Einleitung \u003Ca name=\"1-einleitung\">\u003C/a>\u003C/h2>\n\n\u003Cp>In den letzten Jahren – insbesondere im Jahr 2013 – haben uns zahlreiche Ereignisse gezeigt, dass\nunsere Alltagskommunikation für Lauscher äußerst wertvoll ist. E-Mails gehören zu den heikelsten\nServices in puncto Datenschutz, die User online verwenden und es ist keine leichte Aufgabe, die\nKommunikation privat zu halten. Zwar existieren bereits leistungsstarke Standards wie SSL / TLS und\nOpenPGP, doch die Verwendung und korrekte Einrichtung derselben kann für viele unerfahrene User\nschwierig sein. Da viele Menschen die Einrichtung und Verwendung von Verschlüsselung mit einer\nlangwierigen Einarbeitungszeit assoziieren, kommunizieren sie weiterhin über unsichere Plattformen.\u003C/p>\n\n\u003Cp>Das Ziel von StartMail ist, dieses Problem zu lösen. Wir sehen Privatsphäre als fundamentales\nMenschenrecht an und haben uns der Aufgabe gestellt, dem durchschnittlichen User Privatsphäre und\nSicherheit zu bieten. StartMail wurde entwickelt, um den Menschen zu helfen, ihr Recht auf\nPrivatsphäre mithilfe leistungsfähiger Verschlüsselung für ihre tägliche E-Mail-Kommunikation\nzurückzuerobern.\u003C/p>\n\n\u003Cp>StartMail wurde von den Menschen hinter den Privatsphäre-Suchmaschinen Startpage.com und Ixquick.com\nbegründet. Die Entwicklung dauerte mehr als drei Jahre und war ein natürlicher Schritt vom Angebot\neiner privaten Internet-Suche hin zum Angebot für private und sichere E-Mail-Kommunikation.\u003C/p>\n\n\u003Cp>Dieses Dokument erläutert die von uns getroffenen Entscheidungen in Bezug auf Sicherheitspraktiken\nund den Privatsphäre-Schutz unserer User. Zuerst bieten wir einen kurzen Überblick über unsere\nLeistungen, danach listen wir die wichtigsten Entscheidungen in Bezug auf unsere Erwägungen zur\nKonstruktion während der Gestaltung unserer Service-Architektur auf. Schlussendlich beschreiben wir\ndie getroffenen Entscheidungen im Detail, mit dem Hauptaugenmerk auf sicherheitsorientierte\nVorsichtsmaßnahmen und Funktionen.\u003C/p>\n\n\u003Cp>\u003Ca href=\"#startmail-technisches-white-paper\">Nach oben.\u003C/a>\u003C/p>\n\n\u003Ch2>2. Überblick über StartMail \u003Ca name=\"2-überblick-über-startmail\">\u003C/a>\u003C/h2>\n\n\u003Cp>StartMail ist eine Plattform für sichere E-Mail-Kommunikation. Auf unseren Service kann sowohl von\neinem Web-Interface aus zugegriffen werden als auch über das traditionelle IMAP-Protokoll, das mit\nbestehenden E-Mail-Clients kompatibel ist.\u003C/p>\n\n\u003Cp>Versierte Anwender mit ausreichend Wissen und Erfahrung können von der erweiterten Funktionalität\nprofitieren: Zum Beispiel bietet StartMail diesen Usern die Möglichkeit, ihren\nWiederherstellungscode selbstständig zu speichern, ihren bestehenden OpenPGP-Schlüssel zu\nimportieren und zu verwalten oder auch alle OpenPGP-Interaktionen manuell zu behandeln, um StartMail\nzur Übermittlungsplattform für ihre eigene sichere Kommunikation zu machen.\u003C/p>\n\n\u003Cp>Wir wollen sichere Kommunikation so transparent wie möglich machen. Zu diesem Zweck wird Open PGP\nverwendet. Versierte User haben die Möglichkeit, auf alle Kryptographie bezogenen Funktionen zu\nverzichten und ihre Kryptographie eigenständig zu behandeln und dann über IMAP auf ihre E-Mails\nzuzugreifen. Standardmäßig bietet StartMail jedoch die folgenden Sicherheitsfunktionen für User:\u003C/p>\n\n\u003Cul>\n\u003Cli>Asymmetrische Verschlüsselung und Signatur mit OpenPGP – sowohl für StartMail-User als auch für\nNicht-StartMail-User.\u003C/li>\n\u003Cli>Passwortbasierte Verschlüsselung für User, die kein PGP verwenden.\u003C/li>\n\u003Cli>Operative Gesellschaft und Rechtsträger strikt außerhalb der US-Gerichtsbarkeit.\u003C/li>\n\u003Cli>Minimale Datenspeicherung über User und Verzicht auf Tracking-Cookies, wie in unseren \u003Ca href=\"/de/datenschutz/\">sehr\nstrengen Datenschutzrichtlinien [1] beschrieben\u003C/a>.\u003C/li>\n\u003Cli>Alle Daten im Besitz des Users, einschließlich E-Mails, Präferenzen und Anti-Spam-Profile werden\nim “User-Tresor” verschlüsselt gespeichert.\u003C/li>\n\u003Cli>Eingehende E-Mails für User werden augenblicklich für die spätere Zustellung , wenn der User\nseinen User-Tresor öffnet, mithilfe des öffentlichen Schlüssel des “Queue-Schlüsselpaars”\nverschlüsselt.\u003C/li>\n\u003C/ul>\n\n\u003Cp>\u003Ca href=\"#startmail-technisches-white-paper\">Nach oben.\u003C/a>\u003C/p>\n\n\u003Ch2>3. Konstruktionserwägungen \u003Ca name=\"3-konstruktionserwägungen\">\u003C/a>\u003C/h2>\n\n\u003Cp>Während der Entwicklung von StartMail wurden wir vor mehrere Herausforderungen in Bezug auf\nSicherheit, Datenschutz und Userfreundlichkeit gestellt. In diesem Abschnitt werden wir die\nrelevantesten Entscheidungen behandeln.\u003C/p>\n\n\u003Ch3>3.1. Webmail vs. Desktop-Client \u003Ca name=\"31-webmail-vs-desktop-client\">\u003C/a>\u003C/h3>\n\n\u003Cp>Unser Ziel bei der Entwicklung von StartMail war es, einen anfängerfreundlichen OpenPGP-Client zu\nerschaffen. Wir entschieden uns aus mehreren Gründen, einen Webmail-Client statt einer Desktop-\n(oder mobilen) Anwendung anzubieten. Erstens haben sich viele E-Mail-User daran gewöhnt, über einen\nBrowser auf ihre E-Mails zuzugreifen. Zweitens, da die User erwarten, von verschiedenen Geräten aus\nauf Ihre E-Mails zugreifen zu können, gestattet die Webmail Lösung eine Alternative zu\nOS-spezifischen Anwendungen und erlaubt ihnen, von der weiten Verbreitung zu profitieren, die\nBrowser bieten. Schlussendlich gibt es bereits sichere OpenPGP kompatible Desktop-Clients, die für\ndie Verwendung von StartMail über IMAP konfiguriert werden können.\u003C/p>\n\n\u003Cp>Die StartMail Web-Anwendung ist ein PGP-fähiger Mail-Client für das Web. Trotzdem unterstützen wir\nauch traditionelle E-Mail-Clients, die mit IMAP funktionieren.\u003C/p>\n\n\u003Cp>\u003Ca href=\"#startmail-technisches-white-paper\">Nach oben.\u003C/a>\u003C/p>\n\n\u003Ch3>3.2. Clientseitige vs. Serverseitige Verschlüsselung \u003Ca name=\"32-clientseitige-vs-serverseitige-verschlüsselung\">\u003C/a>\u003C/h3>\n\n\u003Cp>Grundsätzlich können OpenPGP-Operationen (wie Ver- und Entschlüsselung) sowohl auf dem Server als\nauch auf dem Client erfolgen. In StartMail finden alle OpenPGP-Operationen serverseitig statt.\u003C/p>\n\n\u003Cp>Wir haben uns entschieden, die Kryptographie auf dem Server durchzuführen, nachdem wir die\nclientseitige Möglichkeit gewissenhaft geprüft haben. Wir lehnten dies ab, weil OpenPGP-Operationen\nin einem Web-Browser in einem JavaScript-Kontext stattfinden, die absolut nicht die richtige\nUmgebung für Kryptographie ist. Eine Reihe von zwingenden Gründen, warum dies der Fall ist,\nbeschreibt die NCC Group in diesem ausgezeichneten Artikel:\u003C/p>\n\n\u003Cp>\u003Ca href=\"https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/\">https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/\u003C/a>.\u003C/p>\n\n\u003Cp>Zu den Gründen, clientseitige kryptographische Operationen abzulehnen, zählen:\u003C/p>\n\n\u003Cul>\n\u003Cli>\u003Cp>Die Formbarkeit der JavaScript-Laufzeitumgebung bedeutet, dass die Zukunftssicherheit von einem\nTeil eines JavaScript-Codes unmöglich zu gewährleisten ist: Der Server, der JavaScript\nbereitstellt, könnte leicht eine Hintertür im Code platzieren oder der Code selbst könnte während\nder Laufzeit durch ein anderes Script modifiziert werden. Dies verlangt von den Usern das gleiche\nMaß an Vertrauen in den Server, der JavaScript bereitstellt, das sie in die serverseitige\nKryptographie setzen.\u003C/p>\u003C/li>\n\u003Cli>\u003Cp>JavaScript wird in einer Umgebung ausgeführt (Browser), über das der Programmierer extrem wenig\nKontrolle hat. Unter diesen Bedingungen ist es schwierig bis unmöglich, eine sichere\nSpeicherverwaltung bereitzustellen, gegen Timing-Angriffe zu schützen, usw. bereitzustellen. In\neinfachen Worten: JavaScript ist eine schlechte Umgebung für den Umgang mit solch heiklen\nOperationen wie Kryptographie. Darüber hinaus kann ein JavaScript-Code, der in einem Browser\nläuft, auch von anderen Teilen eines im gleichen Browserfenster laufenden Teils eines\nJavaScript-Codes beeinflusst werden und manchmal sogar von anderen Webseiten.\u003C/p>\u003C/li>\n\u003C/ul>\n\n\u003Cp>Diese Bedingungen machen es uns unmöglich, dass gleiche Maß an Sicherheit wie durch die\nBereitstellung von serverseitiger Kryptographie zu gewährleisten.\u003C/p>\n\n\u003Cp>Ein häufig zitierter Vorteil der clientseitigen Kryptographie – zumindest in der Theorie – ist, dass\nweder der Server noch der E-Mail-Anbieter Zugang zum privaten OpenPGP-Schlüssel des Users hat, was\ndas benötigte Vertrauen des Users in den E-Mail-Anbieter reduziert. In der Praxis ist dieser\nSicherheitsvorteil jedoch illusorisch. Die einzige Gelegenheit, bei der private OpenPGP-Schlüssel\ntatsächlich nicht in Kontakt mit irgendeinem Server oder einem zur Verfügung gestellten Server-Code\nkommt ist, wenn die Kryptographie über eine native Desktop-Anwendung (z. B. GnuPG oder GPGtools)\ndurchgeführt wird. StartMail unterstützt dies bereits vollständig mittels IMAP.\u003C/p>\n\n\u003Cp>Clientseitige Kryptographie-Operationen in einem Webbrowser, die JavaScript nutzen, bieten nur einen\noberflächlichen Schutz vor einem Server, der gefährdet ist oder böswillige Absichten verfolgt. Dies\nliegt daran, dass der ausgeführte JavaScript-Code direkt von jenem Server empfangen wird. Auf diese\nWeise wird der Browser zu einer serverseitigen Erweiterung für bestimmte Operationen.\u003C/p>\n\n\u003Cp>Wir sehen die Client-Seite (Browser) vs. Server-Seite-Debatte als sich verändernde Größe und werden\nweiterhin nach technologischen Errungenschaften Ausschau halten, die es uns ermöglichen, unsere\nEntscheidung zu überdenken. Vor allem im Bereich browserbasierter Kryptographie verändern sich die\nVerfügbarkeit und die Qualität der Programmbibliotheken sehr schnell. Wir werden die Umsetzung einer\nclientseitigen Lösung in Erwägung ziehen, sobald Browser-Systeme und verfügbare Software zur nötigen\nReife weiterentwickelt wurden, um vertrauenswürdige kryptographische Operationen zu bieten.\u003C/p>\n\n\u003Cp>Die Vertrauensfrage bleib immer, egal ob OpenPGP-Operationen nun im Browser oder auf dem Server\nstattfinden. Aus diesem Grund glauben wir, dass die „echte Client-Seite“ (native Desktop) die\nsicherste Option ist. Sie gibt den Anwendern die vollständige Kontrolle über ihre\nOpenPGP-Schlüssel-Verwaltung und Kryptographie-Operationen in einer Umgebung, die für diesen Zweck\nbesser geeignet ist als der Browser. Es existieren nach wie vor offensichtliche Probleme mit der\nAnwendererfahrung, der Setup-Komplexität und einem möglichen Datenverlust in Desktop-Clients. Da die\nvolle Kompatibilität bei der Verbindung zu StartMail via IMAP gewährleistet ist, wollen wir auch die\nsicherste browser-basierende Lösung anbieten, die möglich ist.\u003C/p>\n\n\u003Cp>\u003Ca href=\"#startmail-technisches-white-paper\">Nach oben.\u003C/a>\u003C/p>\n\n\u003Ch3>3.3. Clientseitige vs. serverseitige Schlüsselspeicherung \u003Ca name=\"33-clientseitige-vs-serverseitige-schlüsselspeicherung\">\u003C/a>\u003C/h3>\n\n\u003Cp>Unabhängig davon, wo die Verschlüsselung und Entschlüsselung stattfinden, ist eine Diskussion über\nOpenPGP-Schlüsselspeicherung in Ordnung. Clientseitige Schlüsselspeicherung bedeutet, dass der\nprivate OpenPGP-Schlüssel dauerhaft auf dem Computer des Anwenders gespeichert wird (im Gegensatz\nzur Speicherung auf dem Server). Die Anwender speichern den Schlüssel entweder dauerhaft im Browser\noder sie tragen ihren Schlüssel mit sich und stellen ihn bei Bedarf dem Browser zur Verfügung.\u003C/p>\n\n\u003Cp>Browser verfügen über keine sichere Möglichkeit, OpenPGP-Schlüssel zu speichern, die unsere\nStandards erfüllen. Darüber hinaus verwendet die große Mehrheit der Menschen noch immer veraltete\nBrowser. Was in anderen Zusammenhängen mit \u003Ca href=\"https://en.wikipedia.org/wiki/Fault_tolerance\">“graceful degradation”\n[2]\u003C/a> gelöst werden könnte (z.B. das Zurückgreifen auf\neine alternative CSS-Eigenschaft, wenn der Browser die neuere nicht unterstützt), ist in einem\nSicherheitsmodell einfach keine Option. Bis diese Situation nicht besser ist, bevorzugen wir, die\nPGP-Schlüssel unserer Anwender nicht den Gefahren der Lagerung im Browser auszusetzen. Zumal wir uns\n(aus den oben beschriebenen Gründen) für den serverseitigen Ansatz für den Umgang mit\nkryptographischen Operationen entschieden haben, sehen wir kein überzeugendes Argument, die\nSchlüssel Browsern preiszugeben.\u003C/p>\n\n\u003Cp>Es ist wohl nicht notwendig zu erwähnen, dass die Idee, dass Anwender ihre OpenPGP-Schlüssel mit\nsich tragen, ein potentielles Sicherheitsrisiko darstellt. Viele User hätten weder das Wissen noch\ndie Geduld, um die notwendigen Vorkehrungen zu treffen, dass ihre Schlüssel nicht überflüssig\nvervielfacht oder unsicher gelagert werden.\u003C/p>\n\n\u003Cp>\u003Ca href=\"#startmail-technisches-white-paper\">Nach oben.\u003C/a>\u003C/p>\n\n\u003Ch3>3.4. Leistung und Information zu Fehlerbehebung vs. Datenschutz \u003Ca name=\"34-leistung-und-information-zu-fehlerbehebung-vs-datenschutz\">\u003C/a>\u003C/h3>\n\n\u003Cp>Das Behalten eines Protokolls von Aktivitäten auf unseren Servern kann sehr nützlich für\nFehlerbehebungen, Leistungs- und Sicherheitsverbesserungen sein. Doch bei der Entscheidung, welche\nDaten protokolliert werden, entscheiden wir immer zu Gunsten der Privatsphäre und Sicherheit unserer\nUser.\u003C/p>\n\n\u003Cp>Ein essenzielles Beispiel hierfür ist unser Ansatz im Umgang mit Spamfilter-Profildaten. Zusammen\nmit den Standard-Algorithmen verwenden wir Metadaten, um reale Beispiele zu erhalten, was User als\nSpam ansehen und was nicht. Wir haben uns entschieden, diese Informationen im persönlichen Tresor\ndes Users zu speichern (nachfolgend beschrieben), anstatt sie allgemein zu speichern, um die gesamte\nEffektivität unserer Spamfilter zu verbessern. Etwas anderes zu tun würde bedeuten, dass Teile von\nE-Mails unserer User dem ganzen System zur Verfügung stünden, was unsere Verpflichtung, dem\nDatenschutz oberste Priorität einzuräumen, verletzen würde.\u003C/p>\n\n\u003Cp>Eine ähnliche Situation besteht bei der Suchindexierung. Damit die Suchfunktion schnell reagieren\nkann, müssen E-Mails indexiert werden und die Indizes müssen aktuell sein. Dies kann zu jedem\nZeitpunkt geschehen, vorausgesetzt es geschieht bereits, bevor der User eine Suche startet. Im Falle\nvon StartMail können die Suchindizes nur aktualisiert werden, wenn der User eingeloggt ist. Ist er\nnicht eingeloggt, sind E-Mails und Indizes verschlüsselt im User-Tresor gespeichert und die\nIndexierungsoperationen können nicht stattfinden. Diese Einschränkung, die uns zur Indexierung von\nE-Mails ausschließlich nach dem Login beschränkt, bietet für unsere User bessere Privatsphäre und\nSicherheit, während sie nur einen kleinen Nachteil in der Funktionalität mit sich bringt.\u003C/p>\n\n\u003Cp>\u003Ca href=\"#startmail-technisches-white-paper\">Nach oben.\u003C/a>\u003C/p>\n\n\u003Ch3>3.5. Open Source vs Closed Source Software \u003Ca name=\"35-open-source-vs-closed-source-software\">\u003C/a>\u003C/h3>\n\n\u003Cp>Der StartMail Quellcode setzt sich aus Open Source- und Closed Source-Komponenten zusammen. Die Open\nSource-Komponenten bestehen hauptsächlich aus infrastrukturellen Codes (beispielsweise Linux\nBetriebssystem und OpenPGP Cryptographic Suite) sowie Bibliotheken für unsere Web-Anwendung, wie zum\nBeispiel jQuery und AngularJS. Der Code, den wir geschrieben haben, um den Webmail-Service\nbereitzustellen, die User-Tresore verwalten zu können und Redundanzen zu bieten, ist Closed Source.\u003C/p>\n\n\u003Cp>Open Source-Codes bieten gewisse Vorteile in Sachen Sicherheit, da eine Vielzahl von Menschen\nZugriff auf den Quellcode haben und helfen können, ihn noch sicherer zu machen, indem sie Audits\ndurchführen und Sicherheitslücken melden. Wir glauben allerdings, dass diese Vorteile nur bei großen\nProjekten zutreffen, die von einer etablierten Community unterstützt werden. Wenn ein Projekt noch\nzu klein ist, um die Aufmerksamkeit externer Sicherheitsexperten zu gewinnen, kann das\nVeröffentlichen des Quellcodes Risiken bergen, die jegliche Vorteile bei Weitem überwiegen.\nPotenzielle Angreifer gewinnen auf diesem Wege eine mächtige, zusätzliche Waffe: Den Quellcode der\nAnwendung.\u003C/p>\n\n\u003Cp>Aus diesem Grund haben wir uns aus Sicherheitsgründen entschlossen, unseren Quellcode nicht zu\nveröffentlichen und unabhängige Prüfer zu engagieren, die unsere Datenschutz- und\nSicherheitsmaßnahmen belegen sollen. Wenn StartMail wächst, kann es durchaus dazu kommen, dass die\nVorteile bei einer Veröffentlichung unseres Quellcodes gegen etwaige Risiken überwiegen und wir\nunsere Entscheidung noch einmal überdenken.\u003C/p>\n\n\u003Cp>\u003Ca href=\"#startmail-technisches-white-paper\">Nach oben.\u003C/a>\u003C/p>\n\n\u003Ch2>4. Sicherheitsmaßnahmen \u003Ca name=\"4-sicherheitsmaßnahmen\">\u003C/a>\u003C/h2>\n\n\u003Cp>Im vorherigen Abschnitt beschrieben wir die Design-Entscheidungen, die im Laufe der Entwicklung von\nStartMail getroffen wurden. In diesem Abschnitt begutachten wir nun die Sicherheitsmaßnahmen, die\ndie Organisation, Entwicklung, Instandhaltung und Systemarchitektur beeinflussen.\u003C/p>\n\n\u003Ch3>4.1. Prozesse und Grundsätze \u003Ca name=\"41-prozesse-und-grundsätze\">\u003C/a>\u003C/h3>\n\n\u003Cp>Die Priorität von StartMail lag von Anfang an ganz klar bei Sicherheit und Datenschutz. Doch egal\nwie sicher ein System in der Theorie auch ist, wenn ein kritischer Dienst Schwachstellen aufweist,\nkönnen Angreifer selbst sorgfältig durchdachte Sicherheitsmaßnahmen überwinden. Mit diesem Gedanken\nim Hinterkopf starteten wir einen sicherheitsorientierten Entwicklungsprozess, um gewährleisten zu\nkönnen, dass keine Schwächen im System auftreten, wenn sich der Code in der Entwicklung befindet\noder instandgehalten wird. Des Weiteren etablierten wir zahlreiche Verteidigungsschichten, um\nmögliche Schäden so gering wie möglich zu halten.\u003C/p>\n\n\u003Cp>\u003Ca href=\"#startmail-technisches-white-paper\">Nach oben.\u003C/a>\u003C/p>\n\n\u003Ch4>4.1.1. Entwicklungsprozess \u003Ca name=\"411-entwicklungsprozess\">\u003C/a>\u003C/h4>\n\n\u003Cp>Ein sicherer Code ist eine Top-Priorität bei einem Projekt wie StartMail. Natürlich existieren\ndiverse Maßnahmen, um die Folgen potentieller Schwachstellen in unserer Software zu schmälern.\u003C/p>\n\n\u003Cp>Wir haben zahlreiche Maßnahmen etabliert, um sicherzustellen, dass interne und externe Prüfer eine\nobjektive Einschätzung des StartMail-Codes vornehmen können:\u003C/p>\n\n\u003Cul>\n\u003Cli>Die Programmierer, die an StartMail arbeiten, wurden für sichere Entwicklung ausgebildet und haben\nErfahrung auf dem Gebiet.\u003C/li>\n\u003Cli>Ein qualitativ hochwertiger, gut strukturierter und lesbarer Code ist essentiell in Sachen\nSicherheit. Darum geben wir unser Bestes, um zu gewährleisten, dass Gutachter die Struktur und\nFunktionsweisen unseres Codes problemlos verstehen und sich auf das Finden von Schwachpunkten\nkonzentrieren können.\u003C/li>\n\u003Cli>Jede Codezeile wird von mehreren, voneinander unabhängigen Entwicklern auf Qualität und Sicherheit\ngeprüft, ehe sie der Codebasis hinzugefügt wird. Entdeckte Probleme in dieser Phase resultieren in\nder Ablehnung des Codes: Er kann nicht in den Quellcode aufgenommen werden, bevor der Fehler nicht\nberichtigt wurde.\u003C/li>\n\u003Cli>Sicherheitsexperten, die nicht zum Entwickler-Team gehören, führen Sicherheits-Audits des Codes\ndurch. Dasselbe gilt für externe Bibliotheken.\u003C/li>\n\u003Cli>Die Entwicklungs-Infrastruktur (code repository, issue tracker, review tooling) kommt\nausschließlich beim StartMail-Projekt zum Einsatz und ist nur für Teammitglieder und Begutachter\nzugänglich.\u003C/li>\n\u003C/ul>\n\n\u003Cp>\u003Ca href=\"#startmail-technisches-white-paper\">Nach oben.\u003C/a>\u003C/p>\n\n\u003Ch4>4.1.2. Open Source \u003Ca name=\"412-open-source\">\u003C/a>\u003C/h4>\n\n\u003Cp>Wir glauben, dass die Verwendung von Open Source Bibliotheken und Werkzeugen im Gegensatz zu jenen,\ndie von kommerziellen Instanzen kontrolliert werden, oft die sicherere Wahl ist. Stabile Communitys\nstehen hinter der Entwicklung solcher Werkzeuge und die frei zugängliche Quelle erlaubt uns eine\ninterne Prüfung, bevor wir uns dazu entschließen, sie in unsere Anwendung einzubinden. Das ist der\nHauptgrund, weshalb wir, zusätzlich zu dem Code, den wir selbst schreiben, ausschließlich Gebrauch\nvon Open Source-Komponenten machen.\u003C/p>\n\n\u003Cp>Nachdem die Entwickler dieser Werkzeuge Unterstützung brauchen, um ihre Arbeit fortführen zu können,\nhat StartMail bereits an mehrere Open Source-Projekte gespendet, darunter auch \u003Ca href=\"https://www.openbsdfoundation.org/contributors.html\">LibreSSL\n[3]\u003C/a>.\u003C/p>\n\n\u003Cp>\u003Ca href=\"#startmail-technisches-white-paper\">Nach oben.\u003C/a>\u003C/p>\n\n\u003Ch4>4.1.3. Kryptographie \u003Ca name=\"413-kryptographie\">\u003C/a>\u003C/h4>\n\n\u003Cp>Das Rad in Sachen Kryptographie (und Sicherheit im Allgemeinen) neu zu erfinden, ist immer eine sehr\n\u003Ca href=\"https://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-own\">schlechte Idee\n[4]\u003C/a>. Es ist nicht\nbloß unnötig, sondern auch potentiell gefährlich. Die Geschichte zeigt, dass man in der\nKryptographie am besten auf Standardwerkzeuge- und Bibliotheken sowie bewährte Algorithmen\nzurückgreift, die der genauen Prüfung der akademischen und Open Source Communities standgehalten\nhaben. Die meisten Entwickler sind sich dessen bewusst, doch das eigentliche Problem ist recht\nnuanciert. Neben den Dingen, die wir am besten Kryptographie-Experten überlassen, stechen diese\nKategorien am deutlichsten hervor:\u003C/p>\n\n\u003Cul>\n\u003Cli>Kryptographie-Algorithmen für Verschlüsselung, Entschlüsselung und Hashing. Es ist keine besonders\ngute Idee zu versuchen, AES, RSA oder SHA-2 zu ersetzen.\u003C/li>\n\u003Cli>Kryptographische Protokolle wie PBKDF2, HMAC, SSL, und diverse PKCS-Standards. Selbst beim\nVerwenden bewährter kryptographischer Algorithmen ist es normalerweise unklug, neue Schemata\neinzubringen.\u003C/li>\n\u003Cli>Kryptographische Implementierungen. Auch, wenn man Gebrauch von kryptographischen\nMuster-Algorithmen macht und sich im Rahmen des bewährten Protokolls bewegt, ist eine\nImplementierung niemals unerheblich. Solche Aufgaben überlassen wir Open Source-Bibliotheken, die\nvon einer Community geprüft werden. Im Fall von OpenSSL, dem \u003Ca href=\"https://www.openbsd.org/papers/bsdcan14-libressl/\">viel zu wenig Aufmerksamkeit seitens\nder Sicherheits-Commuity [5]\u003C/a> geschenkt wurde,\nverfolgen wir die Entwicklungen genau und ziehen in Betracht, OpenSSL so bald wie möglich durch\neinen geeigneten Ersatz abzulösen.\u003C/li>\n\u003C/ul>\n\n\u003Cp>\u003Ca href=\"#startmail-technisches-white-paper\">Nach oben.\u003C/a>\u003C/p>\n\n\u003Ch3>4.2. Servicearchitektur \u003Ca name=\"42-servicearchitektur\">\u003C/a>\u003C/h3>\n\n\u003Cp>Der vorherige Abschnitt widmet sich den Sicherheitsmaßnahmen auf organisatorischer Ebene und der\nProzessebene. In diesem Abschnitt erklären wir unsere Überlegungen in Bezug auf die generelle\nArchitektur, Webmail, Kontowiederherstellungs-Methoden und IMAP.\u003C/p>\n\n\u003Ch4>4.2.1. Allgemeine Architektur \u003Ca name=\"421-allgemeine-architektur\">\u003C/a>\u003C/h4>\n\n\u003Ch4>4.2.1.1. Transport Layer Security (TLS)\u003C/h4>\n\n\u003Cp>Um mit unseren Usern sicher kommunizieren zu können, verschlüsseln wir jede Verbindung mittels\nTLS-Protokoll. Die genauen Details der Verschlüsselung einer Verbindung zu StartMail hängen davon\nab, worauf sich Server und Client während der Einrichtung der TLS-Verbindung einigen. Durch die\nKonfiguration von sicheren Präferenzen haben die Clients, die diese Anforderungen unterstützen\n(also alle aktuellen Clients), sichere Verbindungen zu uns.\u003C/p>\n\n\u003Cp>StartMail implementiert weitreichende Sicherheitsmaßnahmen in Zusammenhang mit TLS:\u003C/p>\n\n\u003Cul>\n\u003Cli>Unser Server sind entsprechend den aktuellen Standards konfiguriert.\u003C/li>\n\u003Cli>Wir nutzen Zertifikate von Let’s Encrypt, der größten Zertifizierungsstelle (Certificate\nAuthority, CA) der Welt und transparente Non-Profit-Organisation, deren Mission es ist, das\nInternet sicherer zu machen und die Privatsphäre der Internetnutzer zu schützen.\u003C/li>\n\u003Cli>Wir nutzen CAA DNS Records, um zu unterbinden, dass andere CAs Zertifikate für StartMail-Domains\nausstellen.\u003C/li>\n\u003Cli>Wir überwachen die Zertifikatstransparenz-Logs auf die Ausstellung von Zertifikaten für\nStartMail-Domains.\u003C/li>\n\u003Cli>Wir nutzen DNSSEC, um DNS-Einträge zu signieren, wodurch Besucher mit aktiver\nDomain-Signaturüberprüfung vor manipulierten DNS-Antworten geschützt werden.\u003C/li>\n\u003Cli>Wir nutzen HTTP Strict Transport Security (HSTS). Unsere Domain wurde an die HSTS Preload List\nübermittelt.\u003C/li>\n\u003Cli>Wir fördern die Nutzung von Perfect Forward Secrecy (PFS), die vermeidet, dass vergangener\nDatenverkehr entschlüsselt werden kann – auch in dem unwahrscheinlichen Fall, dass unser privater\nSchlüssel kompromittiert wird.\u003C/li>\n\u003Cli>Wir verbessern Datenschutz und Sicherheit für unsere Nutzer durch aktivierte Anheftung des Online\nCertificate Status Protocol (OCSP).\u003C/li>\n\u003Cli>Wir nutzen DANE (TLSA DNS Records) für die Veröffentlichung der Fingerprints von TLS-Zertifikaten,\ndie von unseren E-Mail-Übermittlungssystemen (SMTP) genutzt wird, wodurch Dritte sicherstellen\nkönnen, dass sie mit unseren MX-Servern kommunizieren. Wenn E-Mails an Dritte gesendet werden,\nüberprüfen wir deren DANE-Einträge, um die authentifizierte und verschlüsselte Zustellung zu\ngewährleisten.\u003C/li>\n\u003Cli>Dementsprechend nutzen wir MTA-STS, um Gültigkeitsüberprüfungen der Zertifikate für eingehende\nMails zu erzwingen.\u003C/li>\n\u003C/ul>\n\n\u003Cp>Eine vollständige Übersicht unserer TLS-Verbindung und -Praktiken finden Sie in unserem \u003Ca href=\"https://www.ssllabs.com/ssltest/analyze.html?d=startmail.com\">SSL Labs\nreport [6]\u003C/a>.\u003C/p>\n\n\u003Cp>\u003Ca href=\"#startmail-technisches-white-paper\">Nach oben.\u003C/a>\u003C/p>\n\n\u003Ch4>4.2.1.2. Verschlüsselung bei Übermittlung und Speicherung\u003C/h4>\n\n\u003Cp>Alle Verbindungen zu (und zwischen) StartMail-Servern sind durch eine TLS-Verschlüsselung geschützt.\nObwohl die Verbindung während der Übertragung verschlüsselt ist, empfehlen wir, die E-Mails mithilfe\nvon OpenPGP selbst zu verschlüsseln, sodass sie verschlüsselt auf dem Server gelagert oder gefahrlos\nüber weniger seriöse externe Anbieter geliefert werden können. OpenPGP ist besonders wichtig für die\nKommunikation mit anderen, deren E-Mail-Anbieter sich nicht dem Datenschutz und der Sicherheit\nverschrieben haben und wenn User via IMAP auf ihre E-Mails zugreifen (und dementsprechend Kopien\nihrer E-Mails auf einem Gerät speichern).\u003C/p>\n\n\u003Cp>Das folgende Diagramm illustriert den Unterschied zwischen dem Verschlüsseln der Verbindung und dem\nVerschlüsseln der eigentlichen Daten, und warum beides wichtig ist.\u003C/p>\n\n\u003Cp>\u003Cimg src=\"/static/images/ssl-only.png\" alt=\"\">\u003C/p>\n\n\u003Cp>\u003Cimg src=\"/static/images/ssl-and-openpgp.png\" alt=\"\">\u003C/p>\n\n\u003Cp>\u003Ca href=\"#startmail-technisches-white-paper\">Nach oben.\u003C/a>\u003C/p>\n\n\u003Ch4>4.2.1.3. Header Stripping\u003C/h4>\n\n\u003Cp>Als weiteres Datenschutz-Feature haben wir einige Header-Stripping-Funktionen für eingehende und\nausgehende E-Mails hinzugefügt.\u003C/p>\n\n\u003Cp>Sowohl für ein- als auch für ausgehende E-Mails haben wir folgende Maßnahmen ergriffen:\u003C/p>\n\n\u003Cul>\n\u003Cli>Verschleierung lokaler IP-Adressen und Hostnamen. Dies geschieht, damit keine Informationen über\ndie Infrastruktur preisgegeben wird.\u003C/li>\n\u003Cli>Zurückweisen von E-Mails, die von gesperrten Absenderadressen kommen. Zum Beispiel E-Mails die\nangeblich von \u003Ca href=\"mailto:administrator@startmail.com\">administrator@startmail.com\u003C/a> oder ähnlichen Adressen eingehen.\u003C/li>\n\u003C/ul>\n\n\u003Cp>Speziell für ausgehende E-Mails befreien wir die Header von folgenden Informationen:\u003C/p>\n\n\u003Cul>\n\u003Cli>Mime-Version\u003C/li>\n\u003Cli>Received\u003C/li>\n\u003Cli>User-Agent\u003C/li>\n\u003Cli>X-Enigmail-Version\u003C/li>\n\u003Cli>X-Mailer\u003C/li>\n\u003Cli>X-Originating-IP\u003C/li>\n\u003Cli>X-Pgp-Agent\u003C/li>\n\u003Cli>X-Virus-Scanned\u003C/li>\n\u003C/ul>\n\n\u003Cp>\u003Ca href=\"#startmail-technisches-white-paper\">Nach oben.\u003C/a>\u003C/p>\n\n\u003Ch4>4.2.1.4. Ratenbegrenzung\u003C/h4>\n\n\u003Cp>Wir haben Ratenbegrenzungs-Features etabliert, um das System vor Passwort brute-forcing\n(Ausprobieren verschiedener Passwörter) und username enumeration (Aufzählen von Usernamen) zu\nschützen. Durch eine kurzzeitige (weniger als eine Stunde) Speicherung von IP-Adressen werden\npotenzielle Angreifer identifiziert und die Versuche, Passwörter zu erraten, reduziert. Dies\ngeschieht in Übereinstimmung mit unserer Datenschutzerklärung.\u003C/p>\n\n\u003Ch4>4.2.2. User-Tresor \u003Ca name=\"422-user-tresor\">\u003C/a>\u003C/h4>\n\n\u003Cp>Userdaten werden in sogenannten User-Tresoren gespeichert, die im Grunde nichts anderes sind als\nkomplett verschlüsselte \u003Ca href=\"https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup\">LUKS volume [7]\u003C/a>.\nNachdem User ihr Kontopasswort eingegeben haben, haben sie für die Dauer der Session Zugriff auf\nihre Inhalte.\u003C/p>\n\n\u003Cp>Ist der Tresor geschlossen, kann keine Person auf dessen Inhalte zugreifen, selbst wenn sie\nanderweitig Zugang zum Server hat.\u003C/p>\n\n\u003Cp>Aufgrund unseres User-Tresor-Systems müssen wir keine Passwörter unserer User speichern. Anstatt das\nPasswort eines Users zu überprüfen, verwenden wir es ganz einfach für dessen Versuch, den Tresor zu\nöffnen. Gelingt es, war das Passwort korrekt. Selbstverständlich sind entsprechende\nSicherheitsmaßnahmen vorhanden, die uns vor Timing-Angriffen schützen, wenn wir auf diese Art und\nWeise die Zugangsberechtigungen prüfen.\u003C/p>\n\n\u003Ch4>4.2.2.1. Was speichern wir in User-Tresoren?\u003C/h4>\n\n\u003Cp>Wir speichern die E-Mails der User und alle privaten Angaben zum Userkonto im eigenen User-Tresor\ndes Users (Details finden Sie in unseren Datenschutzrichtlinien). Das bedeutet, dass jedes Mal, wenn\nein User auf seinen Posteingang zugreifen will, er erst den Account, also seinen User-Tresor öffnen\nmuss.\u003C/p>\n\n\u003Ch4>4.2.2.1.1 E-Mail\u003C/h4>\n\n\u003Cp>E-Mails werden im User-Tresor gelagert, sobald sie an einen Account zugestellt wurden. Natürlich\nkönnen Nachrichten, die eingehen, während der User ausgeloggt ist, nicht zugestellt werden, ehe er\nseinen User-Tresor manuell öffnet, indem er sich einloggt.\u003C/p>\n\n\u003Cp>Da wir wollen, dass Daten nur für die rechtmäßigen Eigentümer zugänglich sind, wird ein zusätzliches\nOpenPGP-Schlüsselpaar für jeden User generiert, das als “queue keypair” fungiert. Der private\nSchlüssel wird innerhalb des User-Tresors gespeichert und der öffentliche Schlüssel ist dem Mailer\nService zugänglich. Wenn Post für einen User eintrifft, wird diese mithilfe seines queue’s public\nkey verschlüsselt und in einer Warteschleife gespeichert. Sobald der Tresor geöffnet wird (durch das\nEinloggen des Users), werden diese Mails vom queue’s private key entschlüsselt und in den\nPosteingang des Users verschoben.\u003C/p>\n\n\u003Cp>HINWEIS: Das Queue-Schlüsselpaar ist *vollkommen getrennt* vom OpenPGP-Schlüsselpaar des Accounts,\ndas für die Kommunikation verwendet wird.\u003C/p>\n\n\u003Cp>Natürlich ist der End-to-End-Schutz bereits gegeben, wenn der Absender der Nachricht sich dazu\nentschließt, sie mithilfe von OpenPGP zu verschlüsseln, was wir prinzipiell immer empfehlen. Der\nProzess, den wir oben beschreiben, ist lediglich eine zusätzliche Sicherheitsebene.\u003C/p>\n\n\u003Ch4>4.2.2.1.2 Spam und Metadaten\u003C/h4>\n\n\u003Cp>StartMail ermöglicht den Usern, ihren bayesschen Spam-Filter zu trainieren, indem sie E-Mails im\nWebmail-Interface als Spam oder Nicht-Spam markieren. Die mit dem Spamfilter-Training verbundenen\nMetadaten werden als sensible Userdaten betrachtet, da sie zumindest einen Teil der Inhalte der\nE-Mails eines Users enthalten. Aus diesem Grund werden diese Daten im User-Tresor aufbewahrt. Das\nbedeutet, dass niemand außer dem User Zugriff auf diese Daten hat und dass jeder User seinen\neigenen, persönlich trainierten Spam-Filter hat.\u003C/p>\n\n\u003Ch4>4.2.2.1.3 Schlüsselbund\u003C/h4>\n\n\u003Cp>Wenn sich User bereiterklären, von den OpenPGP-Features im StartMail Webmail-Interface Gebrauch zu\nmachen, wird auch ihr Schlüsselbund im User-Tresor gespeichert. Sie können andere (öffentliche wie\nprivate) Schlüssel für die Kommunikation mit anderen Usern zu ihrem Schlüsselbund hinzufügen.\u003C/p>\n\n\u003Cp>\u003Ca href=\"#startmail-technisches-white-paper\">Nach oben.\u003C/a>\u003C/p>\n\n\u003Ch3>4.2.3. Webmail-Features \u003Ca name=\"423-webmail-features\">\u003C/a>\u003C/h3>\n\n\u003Cp>Wir bieten über unsere Webmail-Plattform verschiedene Features an, die die Sicherheit von\nNachrichten erhöhen. In diesem Kapitel zeigen wir Details über die Implementierung dieser Features\nauf.\u003C/p>\n\n\u003Ch4>4.2.3.1. Passwortgeschützte Nachrichten\u003C/h4>\n\n\u003Cp>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:\u003C/p>\n\n\u003Cul>\n\u003Cli>\u003Cp>Die Nachricht wird mit GnuPG im symmetrischen Modus verschlüsselt, wobei das Passwort die an GnuPG gelieferte Passphrase ist.\u003C/p>\u003C/li>\n\u003Cli>\u003Cp>Im Gegensatz zu einer klassischen, asymmetrisch OpenPGP-verschlüsselten Nachricht, die für alle\nöffentlichen Schlüssel der Empfänger verschlüsselt werden muss, ist diese Verschlüsselungs-Option\nfür jegliche Empfänger verfügbar – selbst jene, die keinen öffentlichen OpenPGP-Schlüssel\nimportiert haben.\u003C/p>\u003C/li>\n\u003Cli>\u003Cp>Die Nachricht wird nicht in einer E-Mail versendet, stattdessen\u003C/p>\n\n\u003Cul>\n\u003Cli>Wird sie verschlüsselt auf unseren Servern gespeichert.\u003C/li>\n\u003Cli>Der Empfänger erhält eine Benachrichtigungs-E-Mail. Diese Mitteilung beinhaltet einen\nLink zu einem StartMail-Server.\u003C/li>\n\u003Cli>Wenn der Empfänger auf den Link in der Benachrichtigungs-Mail klickt, muss das Passwort eingegeben werden, um die E-Mail zu entschlüsseln.\u003C/li>\n\u003Cli>Der Empfänger hat fünf (5) Versuche, die richtige Antwort einzugeben. Hat er alle Chancen\nvertan, ist die Nachricht nicht länger zugänglich. Dies ist eine Maßnahme gegen Brute-Forcing.\u003C/li>\n\u003Cli>Hat der Empfänger die richtige Antwort eingegeben, ist er oder sie imstande, die Inhalte der\nNachricht einzusehen und – auf sicherem Wege – über dasselbe Interface eine Antwort zu\nsenden.\u003C/li>\n\u003C/ul>\u003C/li>\n\u003C/ul>\n\n\u003Cp>Als zusätzliche Sicherheitsmaßnahme werden Nachrichten nach einer bestimmten Zeitspanne\nautomatisch von den StartMail-Servern gelöscht. \u003C/p>\n\n\u003Cp>\u003Ca href=\"#startmail-technisches-white-paper\">Nach oben.\u003C/a>\u003C/p>\n\n\u003Ch4>4.2.3.2. OpenPGP\u003C/h4>\n\n\u003Cp>Wir bieten \u003Ca href=\"https://en.wikipedia.org/wiki/Pretty_Good_Privacy\">OpenPGP functionality [8]\u003C/a> in unserem\nWebmail-Interface an. OpenPGP ist ein Standard-Protokoll, näher beschrieben in \u003Ca href=\"https://tools.ietf.org/html/rfc4880\">RFC 4880\n[9]\u003C/a>. Laut dem OpenPGP-Standard werden zwei separate Schlüssel\nfür das Ver- und Entschlüsseln von Daten verwendet. Jeder User hat sein eigenes Schlüsselpaar: Einen\nprivaten Schlüssel, der zusammen mit einem geheimen Passwort verwendet wird, um Daten und Dateien zu\nentschlüsseln, und einen öffentlichen Schlüssel, der zur Weitergabe an andere entwickelt wurde.\nNachrichten mit einem speziellen öffentlichen Schlüssel können ausschließlich mit dem dazugehörenden\nprivaten Schlüssel entschlüsselt werden.\u003C/p>\n\n\u003Cp>Sobald User ihre OpenPGP-Funktionen aktivieren, werden sie dazu aufgefordert, entweder ein neues\nSchlüsselpaar zu generieren oder ein bereits bestehendes zu importieren.\u003C/p>\n\n\u003Ch4>4.2.3.2.1 Neue OpenPGP-Schlüssel\u003C/h4>\n\n\u003Cp>Wir verwenden das Standard-GnuPG-Tool, um ein neues Schlüsselpaar (einen privaten und einen\nöffentlichen Schlüssel) auf unseren Servern zu generieren. Die dem Schlüsselpaar zugeordnete\nE-Mail-Adresse ist selbstverständlich die StartMail-Adresse des Users.\u003C/p>\n\n\u003Cp>Die generierten Schlüssel sind 4096-bit RSA-Schlüssel.\u003C/p>\n\n\u003Ch4>4.2.3.2.2 Importierte OpenPGP-Schlüssel\u003C/h4>\n\n\u003Cp>User, die bereits ein OpenPGP-Schlüsselpaar besitzen, können dieses in StartMail importieren. Die\nStartMail-Adresse muss dem Schlüsselpaar vor dem Import zugeordnet werden.\u003C/p>\n\n\u003Ch4>4.2.3.2.3 OpenPGP Schlüssel-Management\u003C/h4>\n\n\u003Cp>Das grundlegende Schlüssel-Management ist in der Web-Anwendung von StartMail verfügbar:\u003C/p>\n\n\u003Cul>\n\u003Cli>Ändern der Passphrase des privaten Schlüssels\u003C/li>\n\u003Cli>Schlüssel importieren/exportieren\u003C/li>\n\u003Cli>Schlüssel neu generieren\u003C/li>\n\u003C/ul>\n\n\u003Ch4>4.2.3.2.4 Passphrasen zwischenspeichern\u003C/h4>\n\n\u003Cp>Der private OpenPGP-Schlüssel ist verschlüsselt auf dem Server im User-Tresor gespeichert.\nZusätzlich ist der Schlüssel selbst immer mit einer Passphrase verschlüsselt. Die Verwendung von\nOpenPGP im Web-Interface bedeutet, dass die Passphrase des privaten Schlüssels der Applikation zur\nVerfügung stehen muss, sodass Verschlüsselungs- und Entschlüsselungs-Operationen auf dem Server\nstattfinden können. Wann immer die Passphrase benötigt wird, werden die User zur Eingabe\naufgefordert und können optional wählen, dass sie für die Dauer der Sitzung nicht mehr eingegeben werden muss.\u003C/p>\n\n\u003Cp>Wenn die Zwischenspeicherung-Option gewählt wird, wird die Passphrase verschlüsselt und in-memory\nauf dem Server gespeichert. Der Verschlüsselungs-Schlüssel für die Passphrase ist in einem\nBrowser-Cookie gespeichert. Das bedeutet, dass ein Angreifer, der Zugriff auf die Cookies eines\nUsers gewinnt, die Passphrase selbst trotzdem nicht wiederherstellen kann.\u003C/p>\n\n\u003Cp>Natürlich ist die sicherste – wenn auch etwas umständliche – Option, die Passphrase überhaupt nicht\nzwischenzuspeichern. Aber diese Entscheidung überlassen wir unseren Usern.\u003C/p>\n\n\u003Ch4>4.2.3.2.5 OpenPGP Key Directory\u003C/h4>\n\n\u003Cp>Wenn User ihre OpenPGP-Operationen von StartMail abwickeln lassen, wird der öffentliche Schlüssel\nautomatisch in ein internes Schlüsselverzeichnis aufgenommen. Wenn der User eine verschlüsselte\nE-Mail an einen anderen StartMail-Userverstellt, der ebenfalls OpenPGP in StartMail eingerichtet\nhat, wird der öffentliche Schlüssel des Empfängers aus dem Schlüsselverzeichnis abgerufen. User\nkönnen sich in ihren Einstellungen aus diesem Schlüsselverzeichnis abmelden.\u003C/p>\n\n\u003Cp>HINWEIS: Die öffentlichen Schlüssel werden weder mit StartMail-Usern geteilt, noch sind sie\nöffentlich zugänglich. Sie werden nur verwendet, um die Kommunikation von StartMail-Usern\n*untereinander* transparent zu verschlüsseln. Die User haben jedoch die Möglichkeit, ihre\nöffentlichen OpenPGP-Schlüssel auf den \u003Ca href=\"https://pgp.mit.edu/\">MIT OpenPGP Key Server [10]\u003C/a>\nhochzuladen.\u003C/p>\n\n\u003Cp>\u003Ca href=\"#startmail-technisches-white-paper\">Nach oben.\u003C/a>\u003C/p>\n\n\u003Ch4>4.2.3.2.6 Signieren und Verifizieren einer Signatur\u003C/h4>\n\n\u003Cp>Zusammen mit E-Mail-Verschlüsselung und Entschlüsselung bieten wir im StartMail Web-Interface die\nMöglichkeit, E-Mails mit OpenPGP Signaturen zu signieren. Das Signieren von E-Mails ist sehr\nwichtig: Es erlaubt, die Identität des Absenders zu überprüfen, indem es sicherstellt, dass der\nAbsender der verschlüsselten E-Mail der Eigentümer des privaten Schlüssels ist, der mit seiner\nE-Mail-Adresse übereinstimmt. Standardmäßig werden auch alle über das StartMail Web-Interface\nversendeten OpenPGP-verschlüsselten E-Mails signiert.\u003C/p>\n\n\u003Cp>Das StartMail Web-Interface liefert die visuelle Rückmeldung über die Gültigkeit der\nE-Mail-Signaturen und warnt User, wenn sich Nachrichten mit einer ungültigen Signatur erhalten. Um\ndie Signaturen anderer StartMail-User zu überprüfen, wird deren öffentlicher OpenPGP-Schlüssel\nautomatisch von dem im vorigen Abschnitt erwähnten Schlüsselverzeichnis abgerufen.\u003C/p>\n\n\u003Ch4>4.2.3.2.7 OpenPGP-Schlüsselbund im Tresor\u003C/h4>\n\n\u003Cp>Wie bereits erwähnt ist eines der im User-Tresor gespeicherten Items der OpenPGP Schlüsselbund. Das\nist wichtig, denn ohne den Tresor zu öffnen, steht das Schlüsselpaar des Besitzers dem System nicht\nzur Verfügung. Der Schlüsselbund enthält das Schlüsselpaar des Users und alle anderen Schlüssel, die\ner hochgeladen oder importiert hat.\u003C/p>\n\n\u003Ch4>4.2.3.2.8 OpenPGP und BCC-Empfänger\u003C/h4>\n\n\u003Cp>Mit traditionell PGP-verschlüsselten E-Mails ist die Verwendung des BCC-Feldes,\num Empfänger zu deklarieren, die anderen verborgen bleiben sollen, nicht\nmöglich. Dies erklärt sich aus der Tatsache, dass eine verschlüsselte Nachricht\nauch die Schlüssel-ID enthält, für die die Nachricht verschlüsselt wurde. Jeder\nEmpfänger, der von der Schlüssel-ID weiß, kann herausfinden, wer in die\nNachricht inkludiert ist, indem er die gelisteten Schlüssel in der\nverschlüsselten Nachricht untersucht.\u003C/p>\n\n\u003Cp>Es gibt mehrere Möglichkeiten, diesen Datenlecks vorzubeugen. Wir haben uns entschieden, alle\nBCC-Empfänger von einer Nachricht zu entfernen, die über unseren Webmail-Service gesendet wird.\nAnschließend erstellen und verschlüsseln wir eine separate E-Mail für jeden individuellen\nBCC-Empfänger und nehmen sie vollständig aus der gesendeten Original-Nachricht aus. Auf diese Art\nsickern keinerlei Informationen über die BCC-Empfänger an die anderen Haupt-Empfänger durch.\u003C/p>\n\n\u003Cp>\u003Ca href=\"#startmail-technisches-white-paper\">Nach oben.\u003C/a>\u003C/p>\n\n\u003Ch4>4.2.3.2.9 PGP-Nachricht-Arten (MIME/Inline)\u003C/h4>\n\n\u003Cp>Wir übernehmen vollständig die PGP/MIME-Nachrichtenstruktur bei allen ausgehenden Nachrichten, da\ndies alle Dateianhänge sauber verschlüsselt, ohne Metadaten über sie preiszugeben. Außerdem ist es\nzuverlässiger bei Nicht-ASCII-Text und funktioniert ordnungsgemäß mit HTML-E-Mail.\u003C/p>\n\n\u003Cp>Schlussendlich wird PGP/MIME generell als die am besten geeignete Methode betrachtet und ermöglicht\nallen E-Mail-Clients, die Nachricht ordnungsgemäß anzuzeigen, unabhängig davon, ob sie PGP\nunterstützen oder nicht.\u003C/p>\n\n\u003Cp>Wenn wir eine Nachricht empfangen, die mit PGP/Inline verschlüsselt oder signiert wurde, können wir\nsie korrekt entschlüsseln (sofern wir Zugriff auf den zugehörigen privaten Schlüssel haben) und\nSignaturen verifizieren (sofern wir Zugriff auf den öffentlichen Schlüssel haben). Wenn wir\nPGP/Inline-Antworten beantworten oder weiterleiten, konvertieren wir sie in PGP/MIME.\u003C/p>\n\n\u003Cp>Obwohl PGP/MIME dafür bekannt ist, von einigen älteren E-Mail-Clients nicht unterstützt zu werden,\nlegen wir Wert auf die Datenschutz- und Sicherheitsverbesserungen dieser Struktur und erachten diese\nals wichtiger als die Kompatibilität mit Clients, deren MIME-Kompatibilität eingeschränkt ist.\u003C/p>\n\n\u003Ch3>4.2.4. Wiederherstellung \u003Ca name=\"424-wiederherstellung\">\u003C/a>\u003C/h3>\n\n\u003Ch4>4.2.4.1. Passwort-Wiederherstellung für Persönliche Konten\u003C/h4>\n\n\u003Cp>Sollten User jemals die Passphrase ihres Accounts vergessen, bieten wir zwei Möglichkeiten, sie\nwiederherzustellen:\u003C/p>\n\n\u003Cul>\n\u003Cli>Mit einem Wiederherstellungs-Code\u003C/li>\n\u003Cli>Mit einem Link zum Zurücksetzen an die Wiederherstellungs-E-Mail-Adresse\u003C/li>\n\u003C/ul>\n\n\u003Cp>Bei der Anmeldung können die User zwischen dem Beziehen eines Wiederherstellungs-Codes und dem\nEinrichten einer Wiederherstellungs-E-Mail-Adresse wählen. Der Wiederherstellungs-Code wird\nangeboten, wenn sich der User entscheidet, keine Wiederherstellungs-E-Mail-Adresse zu wählen und zu\nbestätigen.\u003C/p>\n\n\u003Cp>Es ist wichtig zu beachten, dass – unabhängig von der Wahl des Users – automatisch ein Code durch\ndas System generiert wird. Der User ist komplett verantwortlich für dessen sichere Verwahrung. Wenn\nder User keine Wiederherstellungs-E-Mail-Adresse angibt und bestätigt, wird StartMail den Code nicht\nspeichern. Wenn der User eine Wiederherstellungs-E-Mail-Adresse angibt und bestätigt, speichert\nStartMail den Code verschlüsselt. Wir erläutern diesen Prozess in diesem Abschnitt genau.\u003C/p>\n\n\u003Cp>\u003Ca href=\"#startmail-technisches-white-paper\">Nach oben.\u003C/a>\u003C/p>\n\n\u003Ch4>4.2.4.1.1 Wiederherstellung mit einem Wiederherstellungs-Code\u003C/h4>\n\n\u003Cp>Der bei der Anmeldung erhaltene Wiederherstellungscode kann verwendet werden, um das Konto manuell\nzurückzusetzen, falls der User sein Konto-Passwort vergisst.\u003C/p>\n\n\u003Cp>StartMail speichert keine Wiederherstellungscodes für Konten, die keine\nWiederherstellungs-E-Mail-Adressen festgelegt haben. Aus diesem Grund können unsere Mitarbeiter\nUsern nicht weiterhelfen, wenn sie ihren Wiederherstellungscode verloren haben. Es ist uns technisch\nnicht möglich, Konten manuell zurückzusetzen und selbst wenn es möglich wäre, hätten wir keine\nMöglichkeit, die Identität der Person zu überprüfen, die um eine Wiederherstellung gebeten haben.\u003C/p>\n\n\u003Cp>Einen Wiederherstellungscode auf diese Weise herauszugeben würde bedeutet, dass sich die\nVerantwortung für sichere Speicherung zum User hin verschiebt. Wir empfehlen, dass technisch weniger\nversierte Anwender, die eventuell Schwierigkeiten beim sicheren Speichern des\nWiederherstellungscodes haben könnten, eine Wiederherstellungs E-Mail-Adresse angeben und StartMail\ndas Speichern und Wiederherstellen für sie erledigen lassen, falls dies nötig sein sollte.\u003C/p>\n\n\u003Ch4>4.2.4.1.2 Wiederherstellung mit einer Wiederherstellungs-Adresse\u003C/h4>\n\n\u003Ch5>Addressprüfung\u003C/h5>\n\n\u003Cp>Nach der Anmeldung und dem Festlegen einer Wiederherstellungs-Adresse wird eine Überprüfungs-E-Mail\nan die Wiederherstellungs-Adresse gesendet. Es ist sehr wichtig, diese E-Mail zu bestätigen, da\ndieser Schritt StartMail erlaubt, das Eigentumsrecht an der E-Mail-Adresse zu prüfen, die zur\nWiederherstellung angegeben wurde. Sobald die Adresse geprüft ist, kann der User damit das\nZurücksetzen beantragen, falls nötig.\u003C/p>\n\n\u003Cp>HINWEIS: Die User müssen ihre Wiederherstellungs-Adresse bestätigen, bevor sie versuchen, ihr Konto\nzurückzusetzen. Andernfalls sind wir nicht in der Lage, mit dem Prozess fortzufahren.\u003C/p>\n\n\u003Ch5>Speicherung des Wiederherstellungs-Codes\u003C/h5>\n\n\u003Cp>Der Wiederherstellungscode wird automatisch vom Server generiert und unter Verwendung multipler\nVerschlüsselungsschichten in einer OpenPGP-verschlüsselten Datei gespeichert (im nächsten Abschnitt\nwird erklärt, warum dies wichtig ist). Niemand, inklusive StartMail Support-Mitarbeiter oder\nAdministratoren, hat Zugriff zum unverschlüsselten Wiederherstellungscode oder kann manuell einen,\neinem beliebigen Konto zugehörigen, Wiederherstellungscode erzeugen.\u003C/p>\n\n\u003Cp>Wir halten es für sehr wichtig, den Wiederherstellungscode vor menschlichem Zugriff zu schützen. Der\nWiederherstellungscode verleiht jedem, der ihn besitzt, die Macht, das Passwort eines Kontos\nzurückzusetzen. Ein Angreifer, der im Besitz eines solchen Codes wäre, könnte das Konto vollständig\nübernehmen. Wir ergreifen jede notwendige Vorsichtsmaßnahme um sicherzustellen, dass ihn nur der\nrechtmäßige Besitzer erhält.\u003C/p>\n\n\u003Ch5>Zum Entschlüsseln wird mehr Personen als eine benötigt\u003C/h5>\n\n\u003Cp>Der Genehmigungsprozess für eine Wiederherstellungsanforderung ist nicht vollständig automatisiert.\nFür die Entschlüsselung und um die Anfrage zu bestätigen werden zwei verschiedene, hochrangige\nMitglieder des Management-Teams benötigt (um eine Verschlüsselungsschicht zu entfernen). Die\nbeteiligten Personen befinden sich auf verschiedenen Kontinenten (Europa und USA), um sie unter\nverschiedenen Rechtsordnungen zu halten.\u003C/p>\n\n\u003Cp>Dies ist nötig, um zu verhindern, dass eine einzelne Person die Macht hat, eine Anfrage zu\ngenehmigen. Sollte die Autorität einer Person kompromittiert werden, ist für die\nKontowiederherstellung immer eine zusätzliche Interaktion erforderlich.\u003C/p>\n\n\u003Cp>Sobald der zweite Manager die Wiederherstellungsanfrage anerkannt und das Wiederherstellungsfile mit\nseinem Schlüssel entschlüsselt hat, wird die daraus resultierende Datei an das StartMail System\nweitergeleitet, das für die Entfernung der letzten Verschlüsselungsschicht verantwortlich ist und\nden Wiederherstellungscode an die bestätigte Wiederherstellungs-Adresse versendet.\u003C/p>\n\n\u003Cp>\u003Ca href=\"#startmail-technisches-white-paper\">Nach oben.\u003C/a>\u003C/p>\n\n\u003Ch4>4.2.4.2. Kontowiederherstellung\u003C/h4>\n\n\u003Cp>Der Kontowiederherstellungs-Prozess erfordert die Passwortänderung eines User-Tresors. Der Tresor\nist ein \u003Ca href=\"https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup\">LUKS volume [7]\u003C/a> mit mehreren\nSchlüssel-Slots: Ein Slot wird für die Authentifizierung verwendet, ein anderer für die\nWiederherstellung. Eine erfolgreiche Wiederherstellung führt zu folgendem Ergebnis:\u003C/p>\n\n\u003Cul>\n\u003Cli>Der Tresor wird mit dem Schlüssel, der dem Wiederherstellungs-Slot entspricht, aufgesperrt\u003C/li>\n\u003Cli>Der alte Authentifizierungs-Slot wird durch Eingabe eines neuen Passwortes überschrieben\u003C/li>\n\u003Cli>Der alte Wiederherstellungs-Slot wird überschrieben, indem ein neuer Wiederherstellungscode generiert wird.\u003C/li>\n\u003C/ul>\n\n\u003Cp>\u003Ca href=\"#startmail-technisches-white-paper\">Nach oben.\u003C/a>\u003C/p>\n\n\u003Ch4>4.2.5. IMAP und mobile Geräte \u003Ca name=\"426-imap-und-mobile-geräte\">\u003C/a>\u003C/h4>\n\n\u003Cp>User, die über einen separaten E-Mail-Client zugreifen möchten, können dies immer über IMAP tun. Der\nIMAP-Zugriff ist standardmäßig deaktiviert und kann im Bereich Einstellungen aktiviert werden.\u003C/p>\n\n\u003Cp>HINWEIS: Viele User greifen über einen separaten E-Mail-Client auf ihre E-Mails zu und sind an das\nPOP3-Protokoll gewöhnt. IMAP funktioniert auf eine sehr ähnliche Weise, ist aber so konzipiert, dass\nes Nachrichten so lange auf dem Remote-Server speichert, bis sie gelöscht werden, statt sie immer\nauf den Client-Rechner herunterzuladen und vom Server zu löschen.\u003C/p>\n\n\u003Cp>IMAP (im Gegensatz zu POP3) gliedert sich natürlicher in die E-Mail-Ansicht im\nStartMail-Webinterface ein und ermöglicht es den Usern, dennoch von der sicheren Speicherung zu\nprofitieren, die das User-Tresor-System bietet.\u003C/p>\n\n\u003Cp>Wir empfehlen, jedes externe Gerät, das sich via IMAP mit StartMail verbindet, separate zu\nkonfigurieren. Sobald User ein (benanntes) Gerät hinzufügen, erhalten sie eine spezifische\nKombination aus Username, Passwort und IMAP-Serverinformationen, mit denen das Gerät konfiguriert\nwerden kann.\u003C/p>\n\n\u003Cp>Das Erstellen von separaten IMAP-Anmeldeinformationen für jedes Gerät bietet mehrere Vorteile, falls\neines der IMAP-fähigen Geräte (Laptop, Telefon) kompromittiert ist:\u003C/p>\n\n\u003Cul>\n\u003Cli>Ein Angreifer, der in Besitz von gültigen IMAP Anmeldeinformationen ist, hat nur Zugriff auf die\nNachrichten des Users. Es besteht keine Gefahr, dass das komplette StartMail-Konto in diesem\nSzenario von einem Angreifer übernommen werden könnte.\u003C/li>\n\u003Cli>IMAP-Konten können voneinander unabhängig deaktiviert werden.\u003C/li>\n\u003C/ul>\n\n\u003Cp>Das Erstellen von unterschiedlichen Passwörtern für jedes mit StartMail verbundenen Gerätes bietet\nauch einen Überblick, welche externen Dienste auf StartMail zugreifen. Sollte einer dieser Dienste\nverloren oder veraltet sein oder nicht mehr verwendet werden, ist es einfach, das Gerät zu entfernen\nund den Zugriff zu entziehen.\u003C/p>\n\n\u003Cp>\u003Ca href=\"#startmail-technisches-white-paper\">Nach oben.\u003C/a>\u003C/p>\n\n\u003Ch4>4.2.5.1. Automatisches Deaktivieren eines Gerätes\u003C/h4>\n\n\u003Cp>Nach mehreren erfolglosen Authentifizierungsversuchen wird der IMAP-Zugriff auf ein Gerät\ndeaktiviert. User können überprüfen, ob ein Gerät deaktiviert ist, indem Sie sich in Ihr\nStartMail-Konto einloggen, auf die Seite Einstellungen – Mobile/IMAP wechseln und überprüfen, ob das\nbetreffende Gerät als deaktiviert markiert ist.\u003C/p>\n\n\u003Cp>Sobald ein Gerät deaktiviert wurde, kann es nicht erneut aktiviert werden. Ein deaktiviertes Gerät\nkann der User als „neues“ Gerät wieder hinzugefügt werden.\u003C/p>\n\n\u003Ch4>4.2.6. Infrastruktursicherheit \u003Ca name=\"427-infrastruktursicherheit\">\u003C/a>\u003C/h4>\n\n\u003Cp>Unsere Infrastruktur liegt in den Niederlanden und wurde gebaut, um die Sicherheitsanforderungen des\nStartMail-Services zu unterstützen.\u003C/p>\n\n\u003Cp>Als allgemeine Regel isolieren wir die Dienstleistungen und Komponenten so weit wie möglich von\nunseren Anwendungen, um den möglichen Schaden, den ein Angreifer anrichten kann, so gering wie\nmöglich zu halten. So werden User-Tresore in Bezug auf die Infrastruktur auf anderen Servern als\nWeb-Servern gespeichert. Sie kommunizieren miteinander über eine sehr begrenzte API, um die Schäden\nzu minimieren, die von jemandem angerichtet werden, der einen Web-Server kompromittiert.\u003C/p>\n\n\u003Cp>Darüber hinaus haben wir alle Standard-Sicherheitsvorkehrungen getroffen, die in einer sicheren\nHosting-Umgebung erwartet werden wie interne (PFS) TLS-Kommunikation, strenge Firewalls,\nFestplattenverschlüsselung auf allen Maschinen usw. Wir haben auch zusätzliche Maßnahmen ergriffen,\num Protokolle zu anonymisieren, wie sie im Detail in unserer Datenschutzerklärung beschrieben sind.\u003C/p>\n\n\u003Cp>Schlussendlich verwenden wir aktive Protokollierung und Alarmierung, integriert mit einem\nKernel-Level-Audit-System, das uns bei anormalen Aktivitäten auf unseren Servern warnt. Diese\nProtokolle werden regelmäßig auf Aktivitäten überprüft, die auf eine Kompromittierung hinweisen\nkönnten. Darüber hinaus führt eine ausbleibende Bestätigung von Audit-Log-Nachrichten zu einem\nselbstständigen Überwachungs-Alarm.\u003C/p>\n\n\u003Cp>\u003Ca href=\"#startmail-technisches-white-paper\">Nach oben.\u003C/a>\u003C/p>\n\n\u003Ch2>5. Fazit \u003Ca name=\"5-fazit\">\u003C/a>\u003C/h2>\n\n\u003Cp>Die Menschen hinter StartMail verfügen über langjährige Erfahrung mit datenschutzfreundlichen\nDienstleistungen. Unser Ziel war es, einen E-Mail-Service zu schaffen, der das Versprechen\n„Verschlüsselung leicht gemacht“ wirklich hält und Menschen hilft, Ihr Recht auf sichere und private\nKommunikation wiederzuerlangen. Eine Plattform zu schaffen, die verschlüsselte E-Mail-Kommunikation\nfür durchschnittliche Anwender ermöglicht, war ein Prozess, nach der optimalen Kombination aus\nUserfreundlichkeit, Datenschutz und Sicherheit zu suchen.\u003C/p>\n\n\u003Cp>Wir verwenden bewährte Kryptographie-Bibliotheken und setzen auf Standard-Implementierung, um die\nzugrundeliegenden Sicherheitsstruktur zu schaffen. Unser Entwicklungsprozess ist zur Gänze auf die\nBeseitigung von Schwachstellen fokussiert, bevor sie unserer Codebasis hinzugefügt werden. Unser\nsehr strenger (und komplexer) Kontowiederherstellungsprozess verhindert, dass unser Personal die\nFähigkeit hat, Konten zurückzusetzen. Eines der wichtigsten Features von StartMail ist der\npersönliche User-Tresor, der uns erlaubt, alle dem User gehörenden Daten verschlüsselt zu speichern.\u003C/p>\n\n\u003Cp>Wir haben unsere Entscheidungen sorgfältig durchdacht, wie z. B. die Wahl der serverseitigen\nKryptographie versus browserbasierten JavaScript-Lösungen. Wir haben sorgfältig erwogen, wo der\nprivate OpenPGP-Schlüssel gespeichert werden kann, um auch für technisch nicht versierte Anwender\nmaximale Sicherheit zu gewährleisten. Wir haben die Verbesserung unserer Such- und\nSpamerkennungsalgorithmen gegen den Schutz der E-Mail-Inhalte abgewogen und überlegt, ob wir den\nStartMail Source-Code freigeben sollen oder ob die Quelle geschlossen bleibt. In jedem Fall, in dem\nwir die Wahl hatten, entschieden wir uns – und werden es immer tun – für jene Alternative, die die\nSicherheit und Privatsphäre unserer User bevorzugt.\u003C/p>\n\n\u003Cp>Unsere Vorgehensweise bei der Einführung neuer Technologien in unser System ist sehr konservativ.\nWir verlassen uns nur auf bewährte Lösungen, denen die kryptographische Gemeinschaft vertraut, die\nPrivatsphäre unserer User sicher zu schützen. Gleichzeitig haben wir ein wachsames Auge für neue\nMöglichkeiten, um unsere Sicherheitsmaßnahmen zu verbessern. In regelmäßigen Abständen bewerten wir\nunsere Entscheidungen im Hinblick auf neue verfügbare Technologien, um auch weiterhin den sichersten\nund modernsten Service zu bieten.\u003C/p>\n\n\u003Cp>\u003Ca href=\"#startmail-technisches-white-paper\">Nach oben.\u003C/a>\u003C/p>\n\n\u003Ch2>6. Literaturhinweise \u003Ca name=\"6-literaturhinweise\">\u003C/a>\u003C/h2>\n\n\u003Col>\n\u003Cli>\u003Cp>\u003Ca href=\"/de/datenschutz/\">https://www.startmail.com/de/datenschutz/\u003C/a> “StartMail Datenschutz”\u003C/p>\u003C/li>\n\u003Cli>\u003Cp>\u003Ca href=\"https://en.wikipedia.org/wiki/Fault_tolerance\">https://en.wikipedia.org/wiki/Fault_tolerance\u003C/a> “Fault tolerance” (Graceful degradation is a particular type of implementing fault tolerance)\u003C/p>\u003C/li>\n\u003Cli>\u003Cp>\u003Ca href=\"https://www.openbsdfoundation.org/contributors.html\">https://www.openbsdfoundation.org/contributors.html\u003C/a> “OpenBSD contributors list”\u003C/p>\u003C/li>\n\u003Cli>\u003Cp>\u003Ca href=\"https://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-own\">https://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-own\u003C/a> “Why shouldn’t we roll our own?”\u003C/p>\u003C/li>\n\u003Cli>\u003Cp>\u003Ca href=\"https://www.openbsd.org/papers/bsdcan14-libressl/\">https://www.openbsd.org/papers/bsdcan14-libressl/\u003C/a> “LibreSSL – The first 30 days”\u003C/p>\u003C/li>\n\u003Cli>\u003Cp>\u003Ca href=\"https://www.ssllabs.com/ssltest/analyze.html?d=startmail.com\">https://www.ssllabs.com/ssltest/analyze.html?d=startmail.com\u003C/a> “StartMail Qualys SSL Labs report”\u003C/p>\u003C/li>\n\u003Cli>\u003Cp>\u003Ca href=\"https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup\">https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup\u003C/a> “Linux Unified Key Setup”\u003C/p>\u003C/li>\n\u003Cli>\u003Cp>\u003Ca href=\"https://en.wikipedia.org/wiki/Pretty_Good_Privacy\">https://en.wikipedia.org/wiki/Pretty_Good_Privacy\u003C/a> “PGP Encryption”\u003C/p>\u003C/li>\n\u003Cli>\u003Cp>\u003Ca href=\"https://tools.ietf.org/html/rfc4880\">https://tools.ietf.org/html/rfc4880\u003C/a> “RFC 4880”\u003C/p>\u003C/li>\n\u003Cli>\u003Cp>\u003Ca href=\"https://pgp.mit.edu/\">https://pgp.mit.edu/\u003C/a> “MIT PGP Public Key Server”\u003C/p>\u003C/li>\n\u003C/ol>\n",{"ROOT_QUERY":88},["null","__typename",89,"page({\"filter\":{\"slug\":{\"eq\":\"whitepaper\"}},\"locale\":\"de\"})",90,"blog({\"filter\":{\"slug\":{\"eq\":\"whitepaper\"}},\"locale\":\"de\"})",13],"Query",["null","__typename",5,"title",6,"slug",7,"subtitle({\"markdown\":true})",8,"_seoMetaTags",91,"_allSlugLocales",109,"deal",13,"tapfiliateReferralCode",8,"tapfiliateTapS",8,"footerTheme",79,"seoStructuredData",13,"hideTopNavigation",80,"sections",112],[92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108],["null","__typename",11,"tag",12,"attributes",13,"content",6],["null","__typename",11,"tag",15,"attributes",16,"content",13],["null","__typename",11,"tag",15,"attributes",19,"content",13],["null","__typename",11,"tag",15,"attributes",22,"content",13],["null","__typename",11,"tag",15,"attributes",26,"content",13],["null","__typename",11,"tag",15,"attributes",29,"content",13],["null","__typename",11,"tag",15,"attributes",32,"content",13],["null","__typename",11,"tag",15,"attributes",36,"content",13],["null","__typename",11,"tag",15,"attributes",40,"content",13],["null","__typename",11,"tag",15,"attributes",44,"content",13],["null","__typename",11,"tag",15,"attributes",47,"content",13],["null","__typename",11,"tag",15,"attributes",51,"content",13],["null","__typename",11,"tag",15,"attributes",55,"content",13],["null","__typename",11,"tag",15,"attributes",59,"content",13],["null","__typename",11,"tag",15,"attributes",63,"content",13],["null","__typename",11,"tag",15,"attributes",67,"content",13],["null","__typename",11,"tag",15,"attributes",71,"content",13],[110,111],["null","__typename",76,"locale",49,"value",7],["null","__typename",76,"locale",78,"value",7],[113,114],["null","__typename",83,"centeredTitle",80,"subtitle",8,"title",8],["null","__typename",85,"body({\"markdown\":true})",86],1775572983197]