So bleiben deine Daten deine

Alles, was du in jellysuite ablegst, wird auf deinem Gerät verschlüsselt, bevor es bei uns ankommt: Ende-zu-Ende. Wir speichern die verschlossene Fassung und haben nie einen Schlüssel dazu. Hier erklären wir, wie das funktioniert und wo die Grenzen liegen. Die technischen Begriffe stehen jeweils dabei.

Was wir lesen können und was nicht, App für App

Dieselbe Nachricht, zweimal.

Links, was du in Jelly Mail siehst. Rechts, was unsere Datenbank davon hat.

Ein Passwort, eine Kette von Schlüsseln

Die Schlüsselhierarchie folgt einem einfachen Prinzip: Jeder Schlüssel ist mit dem vorherigen verschlüsselt, und der erste wird durch dein Passwort geschützt. Geöffnet wird die Kette auf deinem Gerät, Glied für Glied. Unsere Server speichern jedes Glied verschlossen und haben nichts, womit sie das erste öffnen könnten.

  1. 1Dein Passwort bleibt auf deinem Gerät. Es öffnet deinen Kontoschlüssel.
  2. 2Dein Kontoschlüssel öffnet deine zwei Identitätsschlüssel. Mit dem einen signierst du, was du tust. Der andere empfängt die Schlüssel, die andere mit dir teilen.
  3. 3Die öffnen die Schlüssel deiner Ordner. Der Schlüssel eines Ordners öffnet die Schlüssel darin, bis hinunter zu jeder Nachricht, Seite, Datei und jedem Termin.
  4. 4Der Schlüssel eines Elements öffnet genau dieses eine Element. Wir speichern alles davon und können nichts davon öffnen.

Dein Passwort verlässt nie dein Gerät

Wenn du dich einloggst, führen dein Gerät und unser Server einen Austausch durch, der beweist, dass du dein Passwort kennst. Das Passwort wird nicht gesendet, und auch nichts, woraus es sich ableiten ließe. Wer unsere Datenbank stehlen würde, müsste trotzdem Passwörter einzeln raten, und jeder Versuch ist absichtlich langsam gemacht.

Derselbe Austausch hinterlässt auf deinem Gerät ein Geheimnis, das unser Server nie zu sehen bekommt. Dieses Geheimnis öffnet deinen Kontoschlüssel, den wir nur verschlossen speichern. Lesbar werden deine Daten also genau in dem Moment, in dem du dich einloggst, und zwar auf deinem Gerät.

Unter der Haube

OPAQUE, ein augmented PAKE, mit Argon2id-Stretching darin. Es gibt deinem Gerät einen Export-Key, den der Server nie erfährt, und ein BLAKE2b-Subkey davon verschließt deinen 32 Byte langen Kontoschlüssel. Im Browser liegen die Schlüssel für deine Sitzung unter einem WebCrypto-Schlüssel, der sich nicht exportieren lässt.

Jedes Element hat seinen eigenen Schlüssel

Jeder Ordner, jede Nachricht, Seite, Datei und jeder Termin ist mit einem eigenen Schlüssel verschlossen. Der Schlüssel eines Elements liegt verschlossen mit dem Schlüssel des Ordners, in dem es steckt. Wer einen Ordner öffnet, öffnet also, was drin ist, und nichts daneben. So lässt sich auch beim Teilen genau begrenzen, wer worauf Zugriff hat: Teilst du einen Ordner, gibst du genau einen Schlüssel weiter.

Bei der Verschlüsselung wird jedes Element an seinen Typ, seine ID und die Version seines Schlüssels gebunden. Versucht jemand, gespeicherte Daten einem anderen Element zuzuordnen oder als einen anderen Typ auszugeben, erkennt die App das und öffnet sie nicht. Das gilt auch, wenn wir selbst die Daten manipulieren würden.

Unter der Haube

XChaCha20-Poly1305 mit einem 32-Byte-Schlüssel und jedes Mal einer frischen, zufälligen 24-Byte-Nonce. Jeder Umschlag beginnt mit einem Format-Byte und einem Typ-Tag und ist mit der ID des Elements und seiner Schlüsselversion als Associated Data authentifiziert.

Teilen mit genau der Person, die du meinst

Zum Teilen verschließt dein Gerät den Schlüssel des Elements so, dass nur das Gerät der anderen Person ihn öffnen kann, und signiert ihn, damit sie weiß, dass er von dir kommt. Wir speichern diesen versiegelten Schlüssel und reichen ihn weiter. Öffnen können wir ihn nicht, und wir können auch keinen anderen unterschieben, ohne dass ihre App merkt, dass die Signatur nicht stimmt.

Bleibt das Risiko, dass man von Anfang an den Schlüssel der falschen Person bekommt. Deshalb hat jedes Konto zwölf Sicherheitswörter, die aus seinem Schlüssel berechnet werden. Vergleich sie einmal, persönlich oder in einem Call, und du weißt, dass der Schlüssel wirklich ihr gehört. Deine App merkt sich jeden Schlüssel, den sie gesehen hat, und hält mit einer Warnung an, wenn sich einer ändert.

Wenn du das Teilen beendest, ist der Zugriff sofort weg, und das Element bekommt einen neuen Schlüssel. Elemente darin bekommen neue Schlüssel, sobald sie das nächste Mal geändert werden.

Unter der Haube

Der Schlüssel des Elements kommt für die andere Person in eine X25519 Sealed Box, mit deiner Ed25519-Signatur über das Element, seine Schlüsselversion, den Empfänger und seine Rolle. Schlüssel werden beim ersten Kontakt gepinnt. Die Sicherheitswörter sind zwölf Wörter aus der BIP39-Liste, gewonnen aus einem SHA-256-Hash des Signaturschlüssels.

Mail, innerhalb und außerhalb von jellysuite

Zwischen jellysuite-Konten ist Mail Ende-zu-Ende-verschlüsselt. Das Gerät des Absenders verschließt die Nachricht für jeden Empfänger und signiert sie, und die App zeigt ein grünes Schild, sobald sie geprüft hat, dass der Absender auch der ist, für den er sich ausgibt.

E-Mail ist älter als Verschlüsselung. Mit allen anderen kann Mail deshalb nicht so funktionieren, außer sie nutzen PGP, und wir sagen lieber genau, was dann passiert. Eine Nachricht von außen kommt als normale E-Mail an. Unser Server liest sie einmal im Arbeitsspeicher, verschließt sie mit deinem Schlüssel und speichert nur das. Eine Nachricht, die du nach außen schickst, liest unser Server im Arbeitsspeicher, während sie signiert und weitergereicht wird, danach reist sie wie jede andere E-Mail. Keine von beiden landet unverschlossen auf einer Festplatte, und die App markiert beide als externe Mail.

Zwei Details. Hat die externe Adresse einen PGP-Schlüssel, signiert und verschlüsselt dein Browser die Nachricht selbst, und sie bleibt den ganzen Weg verschlossen. Und eine Nachricht an eine externe Adresse, die du für später planst, wartet auf unserem Server, verschlossen mit einem Schlüssel, den der Server hat, und wird gelöscht, sobald sie verschickt ist.

Unter der Haube

Innerhalb von jellysuite wird der Schlüssel der Nachricht für jeden Empfänger mit X25519 versiegelt und mit Ed25519 signiert. Mit PGP baut dein Browser die Nachricht mit OpenPGP, und unsere Server fügen nur äußere Header und eine DKIM-Signatur über den Chiffretext hinzu.

Jelly Reader holt Feeds wie ein Mixer

Feeds und Artikel liegen auf den Websites anderer Leute, also muss sie jemand abholen. In Jelly Reader macht das unser Fetcher, und der funktioniert wie ein Mixer: Anfragen von allen gehen rein, die Feeds kommen raus, und nichts verrät ihm, welche Anfrage von wem war. Er weiß, dass ein Feed angefragt wurde, aber nicht von wem.

Deine App bezahlt jede Anfrage mit einem anonymen Einmal-Token, das sie sich vorher geholt hat. Das Token zeigt, dass die Anfrage von einem jellysuite-Konto kommt, aber nicht von welchem: Wir signieren Tokens, ohne sie zu sehen, deshalb lässt sich das Token, das du einlöst, nicht dem Moment zuordnen, in dem du es bekommen hast. Der Fetcher bekommt nie deine IP-Adresse, deine Cookies oder dein Konto. Ein beliebter Feed wird einmal für alle abgerufen, die ihm folgen, und auch Bilder kommen über den Fetcher, also sehen auch die Websites dich nie.

Was für uns übrig bleibt: welche Feeds und Artikel abgerufen werden und wie oft. Wer unsere Server live beobachtet, könnte trotzdem versuchen, den Zeitpunkt eines Abrufs mit dem Moment abzugleichen, in dem ein Konto etwas speichert. Deshalb wartet deine App eine zufällige Zeit, bevor sie speichert, was sie geholt hat.

Unter der Haube

Die Tokens sind ein VOPRF über ristretto255: Deine App blendet sie, unsere API signiert sie blind, und ein Batch-DLEQ-Beweis zeigt, dass jedes Konto mit demselben Schlüssel signiert wurde. Den holt sich deine App, ohne sich einzuloggen. Der Webserver entfernt die Client-Adresse, Cookies und identifizierende Header, bevor eine Anfrage beim Fetcher ankommt, und der behält von jedem eingelösten Token nur einen Hash. Alles, was du in Reader aufbewahrst, wird wie gewohnt auf deinem Gerät versiegelt.

Dein Gerät

Fragt einen einzelnen Feed an, mit einem Token, das es vorher erzeugt hat.

theverge.com/rss FyYTkib-u841MCvQ

Deine Feed-Liste bleibt hier, verschlüsselt.

Die Adresse und das Token. Keine Cookies, kein Konto, keine IP-Adresse.

Unser Fetcher

  • Sieht: Dass jemand diesen Feed angefragt hat
  • Sieht: Ein gültiges Token, das jetzt verbraucht ist
  • Sieht nie: Wer gefragt hat: kein Konto, keine Cookies, keine IP-Adresse

Dank gemeinsamem Cache wird ein beliebter Feed nur einmal für alle abgerufen.

Eine Anfrage, von uns.

Die Website

  • Sieht: Dass unser Fetcher gefragt hat
  • Sieht nie: Dich, deine IP-Adresse oder deine Cookies

Bilder im Feed und in den Artikeln kommen ebenfalls über den Fetcher, also sieht die Website deine IP-Adresse auch dann nicht, wenn du sie dir anschaust.

Ein Wiederherstellungsschlüssel, und keine Hintertür

Wir speichern deinen Kontoschlüssel zweimal: einmal mit deinem Passwort verschlossen und einmal mit einem Wiederherstellungsschlüssel, den du bei der Registrierung angezeigt bekommst. Vergisst du dein Passwort, kannst du mit dem Wiederherstellungsschlüssel ein neues setzen.

Eine dritte Kopie gibt es nicht. Wir können dein Passwort nicht für dich zurücksetzen, weil wir deinen Kontoschlüssel nie unverschlüsselt haben. Verlierst du Passwort und Wiederherstellungsschlüssel, kann niemand deine Daten zurückholen, auch wir nicht. Das ist der Preis für einen Dienst, den niemand dazu bringen kann, deine Sachen zu lesen.

Im Team gilt dasselbe. Deine Organisation kann ein Konto unter ihrer Domain anlegen, sperren oder löschen, aber nicht lesen oder wiederherstellen. Kein Admin hat einen Schlüssel dafür.

Unter der Haube

Ein zufälliger 32-Byte-Schlüssel, angezeigt in Base32-Gruppen. Ein BLAKE2b-Subkey davon verschließt deinen Kontoschlüssel. Ein zweiter wird als SHA-256-Hash gespeichert und beweist bei der Wiederherstellung, dass du den Schlüssel hast.

Wenn die App ohne Verbindung arbeitet

In den Apps für Mac, Linux und iPhone kannst du ein Konto offline nutzbar halten. Das Gerät hat dann genau das, was unser Server für dich hat, weiterhin verschlossen, und es geht nichts Neues an uns. So ist es geschützt:

Offline aus (der Standard)

Von deinen Inhalten bleibt nichts auf dem Gerät. Entsperrt liegt dein Schlüssel unter dem eigenen Schlüssel des Geräts; gesperrt ist er nicht da, und zum Anmelden brauchst du dein Passwort und unseren Server.

Offline an, App entsperrt

Deine verschlossenen Inhalte liegen auf dem Gerät, und dein Schlüssel ist verfügbar, so wie heute, während du die App nutzt. Er öffnet sich mit dem Login deines Computers oder Handys und lässt sich offline nicht erraten.

Offline an, App gesperrt (Mac, iPhone)

Dein Schlüssel ist an die Secure Enclave gebunden und öffnet sich nur mit Touch ID, Face ID oder dem Gerätepasswort, und die Hardware begrenzt die Versuche. Die Inhalte auf dem Gerät sind verschlossen und ohne ihn nicht lesbar.

Offline an (Linux)

Touch ID gibt es hier nicht. Dein Schlüssel bleibt also, wie er ist, solange du angemeldet bist, und die App sperrt sich nicht nach einer Weile von selbst. Sperr stattdessen deinen Bildschirm. „Lock now“ sperrt trotzdem, und zum Entsperren braucht es dann den Server. Dasselbe gilt für einen Mac ohne Touch ID.

Wenn du das Gerät verlierst oder das Team verlässt

Der Zugriff eines Geräts mit Internetverbindung wird wie gewohnt gesperrt. Eines, das offline bleibt, öffnet dein Konto nicht mehr, wenn es 30 Tage lang unseren Server nicht erreicht hat.

Jelly Vault lässt keine Kopie bei uns

Alles andere in jellysuite liegt verschlossen auf unseren Servern. Jelly Vault, unser Passwortmanager (in der Vorschau), geht einen Schritt weiter: Dein Tresor liegt nur auf deinen eigenen Geräten, und kein Server hat eine Kopie davon, nicht mal verschlüsselt. Seine Einträge, sein Schlüssel, dein Master-Passwort und deine 24 Wörter lange Wiederherstellungsphrase erreichen uns nie. Passwort und Phrase werden nirgends gespeichert: Nur du kennst sie.

Deine Geräte synchronisieren sich direkt miteinander. Sind sie nah beieinander, reden sie über Bluetooth. Sind sie getrennt, können sie über jellysuite reden: Unser Relay reicht versiegelte Bytes zwischen zwei deiner Geräte weiter, solange beide verbunden sind, und behält nichts. Nichts wird gespeichert, in eine Warteschlange gestellt oder geloggt. Nur deine gekoppelten Geräte können diese Bytes öffnen, und die Einstellung „Nearby only“ hält ein Gerät ganz vom Relay fern.

Verlierst du alle Geräte und hast kein Backup, kann niemand deinen Tresor wiederherstellen. Nicht mal wir.

Unter der Haube

Ein zufälliger 32-Byte-Tresorschlüssel versiegelt jede Änderung mit XChaCha20-Poly1305, gebunden an den Tresor, das Gerät und seine Sequenznummer. Das Master-Passwort kommt über Argon2id (256 MiB, drei Durchläufe) an diesen Schlüssel, die Wiederherstellungsphrase (24 BIP39-Wörter) über eine zweite Verschlüsselung. Jedes Gerät führt ein Log seiner eigenen Änderungen, signiert mit seinem Ed25519-Schlüssel, und die Geräte synchronisieren über eine Noise-XX-Sitzung, über Bluetooth genauso wie über das Relay. Beim Koppeln fließt ein Geheimnis aus dem QR-Code oder den sechs Wörtern in den Handshake ein, damit sich das Relay nicht dazwischenschalten kann.

Auf dem Gerät

Der Tresor liegt im eigenen Ordner der App, verschlossen mit dem Tresorschlüssel. Er öffnet sich mit deinem Master-Passwort, und das ist absichtlich langsam zu erraten: Es gibt keinen Server, der Versuche zählt, also bremsen die Kosten jedes einzelnen Versuchs.

Face ID und Touch ID (iPhone, Mac)

Der Tresorschlüssel ist zusätzlich mit einem Schlüssel in der Secure Enclave verschlossen, den nur dein Gesicht oder Finger öffnet und der den Chip nie verlässt. Richtest du Face ID neu ein, funktioniert dieser Schlüssel nicht mehr. Du kannst den Tresor mit deinem Master-Passwort öffnen und Face ID anschließend erneut dafür einrichten. Unter Linux gibt es nur das Master-Passwort.

AutoFill auf dem iPhone

Ist AutoFill an, wird eine Kopie deiner Logins an die Secure Enclave des iPhones versiegelt, geöffnet mit Face ID (oder dem Code, wenn du das gewählt hast), und daneben liegt eine unverschlüsselte Liste von Websites und Benutzernamen. So funktionieren Safari und AutoFill, ohne dass der Tresor geöffnet werden muss.

Die Wiederherstellungsphrase

24 Wörter, die du aufschreibst, wenn du den Tresor anlegst, und ein zweiter Weg zu seinem Schlüssel. Mit der Phrase und einem deiner Geräte oder einer Backup-Datei lässt sich ein vergessenes Master-Passwort ersetzen.

Wenn du ein Gerät verlierst

Seine Kopie bleibt hinter deinem Master-Passwort verschlossen und lässt sich nicht aus der Ferne löschen. Entferne es auf einem deiner anderen Geräte: Der Tresor wechselt auf einen neuen Schlüssel, den das verlorene Gerät nicht hat, und was es später schickt, wird ignoriert. Könnte jemand dein Master-Passwort kennen, ändere es im selben Schritt.

Abmelden und Konto löschen

Meldest du dich von jellysuite ab, bleibt der Tresor auf dem Gerät, weiterhin verschlossen. Löschst du dein Konto, wird nach einer Warnung der Tresor auf diesem Gerät gelöscht, zusammen mit allen aus Safari gespeicherten Logins, die noch auf ihn gewartet haben; deine anderen Geräte behalten ihre Kopien.

Wovor Verschlüsselung nicht schützt

Die Verschlüsselung schützt deine Inhalte. Es gibt aber Grenzen, die wir hier offenlegen.

Die Muster rund um deine Daten

Unsere Server sehen Größen, Zeitpunkte und mit wem du teilst. Das ist weniger als bei den meisten Diensten, aber nicht nichts. Die Transparenzseite listet es für jede App auf.

Wer für ein Konto bezahlt

Wer bezahlt, verknüpft einen echten Namen und eine Rechnungsadresse mit seinem Handle. Diese Angaben liegen bei Stripe, unserem Zahlungsanbieter, nicht auf unseren Servern; die kennen nur deinen Tarif und ob er bezahlt ist. An deinen Inhalten ändert das nichts: Weder wir noch Stripe können sie lesen.

Ein Gerät, das jemand anderes kontrolliert

Auf deinem Gerät sind deine Daten entschlüsselt, damit du sie nutzen kannst. Malware auf diesem Gerät, oder jemand an deinem entsperrten Laptop, sieht, was du siehst.

Mail, die nach außen geht

Sobald eine Nachricht ein Postfach bei einem anderen Anbieter erreicht, gelten dort dessen Regeln.

Der App-Code in deinem Browser

Im Web führt dein Browser den App-Code aus, den unser Server ihm schickt. Die Desktop-Apps bringen stattdessen ihren eigenen Code mit, und der wichtigste Code ist offen, damit ihn jeder prüfen kann.

Prüf es selbst

Die Verschlüsselungsbibliothek und der Client-Kern sind Open Source unter MIT. Nichts davon ist selbstgebastelt: Es baut auf libsodium und OPAQUE auf, beide breit geprüft, und für PGP-Mail auf OpenPGP.js.

Die technischen Namen

Elemente verschließen
XChaCha20-Poly1305, 32-Byte-Schlüssel, jedes Mal eine frische, zufällige 24-Byte-Nonce
Gestempelte Umschläge
Ein Format-Byte und ein Typ-Tag, authentifiziert mit der ID des Elements und seiner Schlüsselversion
Einen Schlüssel für eine Person verschließen
X25519 Sealed Boxes, vom Absender mit Ed25519 signiert
Einloggen
OPAQUE (ein augmented PAKE), mit Argon2id darin
Schlüssel ableiten
BLAKE2b als Keyed Hash mit festen Kontext-Strings
Sicherheitswörter
Zwölf Wörter aus der BIP39-Liste, aus einem SHA-256-Hash des Signaturschlüssels der Person
Link- und Wiederherstellungsgeheimnisse
32 zufällige Bytes; BLAKE2b-Subkeys zum Verschließen und zum Beweisen, der Beweis als SHA-256 gespeichert
PGP-Mail
OpenPGP-v4-Schlüssel (Ed25519 und X25519), im Browser signiert und verschlüsselt
Jelly Vault
Argon2id für das Master-Passwort, eine 24-Wort-Wiederherstellungsphrase nach BIP39, Noise XX zwischen den Geräten, ein P-256-Schlüssel in der Secure Enclave für Face ID und Touch ID
Bibliotheken
libsodium; OPAQUE über @serenity-kit/opaque; OpenPGP.js
Zum Code