Teilen in Sapherbox: Ihr Gerät übergibt den Schlüssel

Ein Klick auf „Teilen“ sieht in Sapherbox aus wie überall: eine Adresse, eine Rolle, eine Schaltfläche. Was dahinter geschieht, ist aber grundlegend anders. Der Server kann nämlich genau das nicht, was jede herkömmliche Freigabe braucht. Er kann dem Empfänger keinen Zugriff auf den Ordner geben, weil er selbst keinen Schlüssel zum Ordner hat. Der Schlüssel muss von Ihrem Gerät auf das Gerät des Empfängers gelangen. Der Server darf ihn dabei nur in einer Form transportieren, die er selbst nicht öffnen kann.

Diese Übergabe ist der Kern des Ende-zu-Ende-verschlüsselten Teilens. Hier setzen auch die meisten interessanten Angriffe an. Ein Server, der Ihre Dateien nicht lesen kann, kann trotzdem versuchen, sich in eine Freigabe einzuschleusen. Er könnte Ihnen einen falschen öffentlichen Schlüssel für den Empfänger unterschieben. Er könnte ändern, für wen eine Freigabe gilt. Oder er fügt einen Empfänger hinzu, den Sie nie ausgewählt haben. Dieser Artikel beschreibt drei Maßnahmen, mit denen Sapherbox dafür sorgt, dass eine Freigabe genau das bewirkt, was Sie wollten. Es versiegelt den Schlüssel für den Empfänger, signiert die Freigabe und pinnt die Identität des Empfängers, damit ein ausgetauschter Schlüssel auffällt.

Was eine Freigabe transportieren muss

Jeder Ordner in Sapherbox hat ein eigenes Schlüsselpaar, das klassische und Post-Quanten-Verfahren kombiniert, und dazu ein privates Schlüsselbündel, mit dem er sich öffnen lässt. Wer dieses Bündel hat, kann den Namensschlüssel des Ordners öffnen und jeden Dateischlüssel darunter, auch in Unterordnern. Denn jedes Element ist für den Ordner versiegelt, in dem es liegt. Einen Ordner mit einer Person zu teilen bedeutet deshalb genau eines: Dieses Bündel muss zu ihr gelangen, und zu niemandem sonst.

Das Bündel ist klein, nur wenige Kilobyte, und außerhalb eines Browsers liegt es nie im Klartext vor. Ihr Browser hat es, weil Sie den Ordner geöffnet haben. Der Browser des Empfängers bekommt es, sobald die Freigabe abgeschlossen ist. Dazwischen liegt es als Freigabeeintrag auf dem Server. Dieser Datensatz legt fest, welches Konto oder welche Gruppe welchen Ordner oder welche Datei mit welcher Rolle öffnen darf. Und er enthält das versiegelte Bündel.

Versiegeln: eine Box, die nur der Empfänger öffnen kann

Zum Versiegeln holt Ihr Browser die öffentlichen Schlüssel des Empfängers vom Server. Es sind zwei, ein RSA-4096-Schlüssel und ein ML-KEM-768-Schlüssel. Dieses hybride Paar hat jedes Konto. Beim Versiegeln kommen beide gleichzeitig zum Einsatz.

Ihr Browser erzeugt einen zufälligen Wert von 32 Byte und verpackt ihn mit dem RSA-Schlüssel des Empfängers. Danach führt er mit dem Post-Quanten-Schlüssel des Empfängers eine ML-KEM-Kapselung aus. Sie liefert ein zweites gemeinsames Geheimnis und ein Chiffrat, das nur dieser Schlüssel wieder entkapseln kann. Die beiden Geheimnisse werden aneinandergehängt und durch eine Schlüsselableitungsfunktion geschickt. Heraus kommt ein einziger Inhaltsschlüssel, der das Bündel mit AES-256-GCM verschlüsselt. Die Freigabe speichert den mit RSA verpackten Wert, das ML-KEM-Chiffrat und das verschlüsselte Bündel. Mehr nicht.

Die Kombination hat einen Zweck. Ein Angreifer muss beide Verfahren brechen. Fällt RSA einem künftigen Quantencomputer zum Opfer, schützt das ML-KEM-Geheimnis den Inhaltsschlüssel weiter. Zeigt sich bei ML-KEM eine Schwachstelle, die bisher niemand gefunden hat, schützt weiterhin RSA. Unsere Überlegungen dazu haben wir ausführlicher beschrieben. Hier zählt etwas anderes. Die Versiegelung geschieht auf Ihrem Gerät, mit den öffentlichen Schlüsseln des Empfängers, und das Ergebnis nützt niemandem, der den Server kontrolliert.

Bei der Rolle Uploader darf der Empfänger Dateien hinzufügen, aber nicht lesen. Hier versiegelt der Browser statt des ganzen Bündels nur den Namensschlüssel des Ordners. Der Empfänger sieht also, wohin er etwas ablegt, und sonst nichts.

Signieren: eine Freigabe, die sich weder fälschen noch verändern lässt

Das Versiegeln sichert die Vertraulichkeit, aber nicht die Integrität. Ein Server, der Freigaben speichert, könnte im Prinzip selbst neue anlegen. Er könnte das versiegelte Bündel, das Sie für Ihre Kollegin erstellt haben, einem anderen Konto zuordnen. Er könnte die Rolle von Viewer auf Co-owner ändern. Verschlüsselung allein verhindert nichts davon, denn für keinen dieser Schritte muss er das Bündel lesen.

Deshalb wird jede Freigabe signiert. Jedes Konto hat einen Ed25519-Signaturschlüssel, den der Browser bei der Registrierung erzeugt. Der private Teil liegt im selben verschlüsselten Identitätsumschlag wie die übrigen privaten Schlüssel. Wenn Ihr Browser eine Freigabe anlegt, signiert er eine kanonische Nachricht. Sie verknüpft den Ordner, den Empfänger, einen Hash des versiegelten Schlüssels, die Rolle und Ihre eigene Identität. Ändert sich auch nur einer dieser Werte, ist die Signatur nicht mehr gültig.

Der Server prüft die Signatur, bevor er die Freigabe speichert. Passt sie nicht zum veröffentlichten Signaturschlüssel der freigebenden Person, weist er die Freigabe ab. Mit einem gestohlenen Sitzungstoken lassen sich deshalb keine Freigaben erzeugen, denn der Signaturschlüssel gehört nicht zum Token. Der Browser des Empfängers kann die Signatur beim Lesen der Freigabe außerdem erneut prüfen, und zwar gegen den Signaturschlüssel, den er für die freigebende Person gepinnt hat. Hätte der Server eine Freigabe erfunden oder nachträglich verändert, fiele das also am anderen Ende auf.

Signaturen schützen die Integrität, nicht die Vertraulichkeit. Erst durch sie wird „Diese Person hat die Freigabe für diesen Empfänger mit dieser Rolle angelegt“ zu einer überprüfbaren Tatsache statt einer bloßen Behauptung in einer Datenbank.

Pinnen: bemerken, wenn sich ein Schlüssel ändert

Gegen einen bestimmten Angriff helfen die ersten beiden Maßnahmen allerdings nicht. Ihr Browser hat die öffentlichen Schlüssel des Empfängers vom Server geholt. Was, wenn der Server gelogen und Ihnen Schlüssel untergeschoben hat, die er selbst kontrolliert? Dann würden Sie das Bündel für den Angreifer versiegeln statt für Ihre Kollegin.

Die Antwort besteht aus zwei Teilen. Erstens sind die öffentlichen Schlüssel jedes Kontos selbstzertifiziert. Der Signaturschlüssel der Person signiert ihren RSA-Schlüssel, ihren ML-KEM-Schlüssel und den Signaturschlüssel selbst als Einheit. Tauscht der Server auch nur einen dieser Schlüssel aus, schlägt die Zertifizierung fehl. Dann wird die Freigabe abgelehnt, mit einer klaren Meldung, dass die veröffentlichten Schlüssel des Empfängers nicht zu seiner Signaturidentität passen.

Zweitens merkt sich Ihr Browser etwas. Wenn Sie zum ersten Mal mit jemandem teilen, wird der Signaturschlüssel dieser Person gepinnt. Er wird in einem kleinen Speicher festgehalten, der mit Ihrem eigenen Account Master Key verschlüsselt ist. Dieser Speicher liegt in einer Form auf dem Server, die der Server nicht lesen kann, und steht Ihnen so auf allen Geräten zur Verfügung. Bei jeder weiteren Freigabe an diese Person prüft der Browser den angebotenen Schlüssel gegen den gepinnten. Die Prüfung gilt der Person, nicht bloß einer Kontonummer. Taucht eine bekannte Adresse unter einem neuen Konto auf, vergleicht der Browser den neuen Schlüssel mit dem, der für diese Adresse gepinnt ist. Stimmen beide überein, läuft die Freigabe ohne Rückfrage durch. Weichen sie ab, wird die Freigabe gestoppt, und Sie sehen einen Dialog.

Der Dialog benennt beide Möglichkeiten offen. Ein geänderter Schlüssel kann legitim sein. Dann hat die Person ihr Konto zurückgesetzt und neue Schlüssel erzeugt. Er kann aber auch bedeuten, dass jemand die Freigabe abfängt. Der Dialog zeigt beide Fingerabdrücke, den gepinnten und den neuen. Er bittet Sie, den neuen über einen anderen Kanal mit dem Empfänger abzugleichen, bevor Sie dem neuen Schlüssel vertrauen. Solange Sie das nicht tun, wird nichts für den neuen Schlüssel versiegelt. Dieses Prinzip heißt „Trust on First Use“ und folgt demselben Modell wie SSH. Es hat auch dieselbe ehrliche Grenze: Dem allerersten Kontakt muss man vertrauen, alles danach wird geprüft.

Was der Server beim Teilen sieht

Der Server sieht, dass eine Freigabe angelegt wurde. Er sieht, für welchen Ordner, für welchen Empfänger, mit welcher Rolle, von wem und wann. Das versiegelte Bündel und die Signatur sieht er nur als undurchsichtige Bytes. Er prüft die Signatur, speichert den Datensatz und schreibt einen Audit-Eintrag mit dem maskierten Ordnernamen. Das Bündel kann er nicht öffnen. Die Freigabe kann er nicht verändern, ohne die Signatur ungültig zu machen. Und die Schlüssel des Empfängers kann er nicht austauschen, ohne dass die Selbstzertifizierung scheitert oder der Pin anschlägt.

Zwei Dinge kann er trotzdem tun. Er kann eine Freigabe zurückhalten. Oder er kann veraltete öffentliche Schlüssel für einen Empfänger ausliefern, mit dem Sie noch nie etwas geteilt haben. Das Erste ist eine Dienstverweigerung, und beide Seiten bemerken sie. Das Zweite ist die Lücke beim Erstkontakt, die sich durch Pinnen nicht schließen lässt. Deshalb zeigen wir den Fingerabdruck an. Und deshalb empfehlen wir allen, die etwas Vertrauliches mit einer neuen Person teilen, den Fingerabdruck einmal über einen anderen Kanal zu vergleichen.

Entzug in einem Satz

Aus all diesen Gründen genügt es nicht, die Freigabe zu löschen, wenn jemand entfernt werden soll. Die Person hat das Bündel womöglich noch zwischengespeichert. Beim Entzug werden deshalb die Schlüssel des Ordners rotiert und für die verbleibenden Mitglieder neu versiegelt, mit frischen Signaturen. Darüber haben wir einen eigenen Artikel geschrieben. Übergabe und Entzug sind zwei Hälften desselben Konzepts. Schlüssel wandern von Gerät zu Gerät, und der Server transportiert immer nur verschlossene Boxen.

Fragen?

Wenn Ihr Sicherheitsteam die kanonischen Nachrichtenformate, die Testvektoren oder den Aufbau des Pin-Speichers im Detail sehen möchte, schreiben Sie uns an hello@sapherbox.com.