Verschlüsselte Ko-Bearbeitung mit Collabora Online: So arbeitet ein WOPI-Gateway mit Schlüsseln im HSM

Gemeinsames Bearbeiten im Browser und Ende-zu-Ende-Verschlüsselung schließen sich in Nextcloud bisher aus: Ein Editor wie Collabora Online braucht das Dokument im Klartext, und ein Ende-zu-Ende-verschlüsselter Ordner liefert es ihm nicht. Dieser Artikel zeigt einen dritten Weg, den DuoKey SecureFolder umsetzt: ein WOPI-Gateway, das das Dokument nur im Arbeitsspeicher entschlüsselt, während Nextcloud ausschließlich Chiffrat speichert und der Hauptschlüssel im HSM der Organisation bleibt.

Er richtet sich an Architektinnen, Administratoren und Sicherheitsverantwortliche aus der Nextcloud- und openDesk-Community, die verstehen wollen, was dabei technisch passiert und wo die Grenzen liegen.

---

Inhaltsverzeichnis

1. WOPI in zwei Minuten
2. Das Gateway als WOPI-Host
3. Der Weg eines Dokuments, Schritt für Schritt
4. Mehrere Bearbeiter, eine Sitzung
5. Sicherheitsentscheidungen im Detail
6. Zwei unabhängige Prüfungen
7. Grenzen und Restrisiken
8. Kompatibilität
9. Quellen

---

WOPI in zwei Minuten

WOPI (Web Application Open Platform Interface) ist das Protokoll, über das ein Online-Editor eine Datei von einem Speicher holt und wieder zurückschreibt. Es kennt zwei Rollen:

• Der WOPI-Client ist der Editor: Collabora Online oder OnlyOffice Docs.
• Der WOPI-Host stellt die Datei bereit: normalerweise Nextcloud selbst, mit der App Nextcloud Office.

Der Editor ruft beim Host im Wesentlichen vier Operationen auf: CheckFileInfo (Metadaten und Rechte), GetFile (Inhalt lesen), PutFile (Inhalt schreiben) und die Sperroperationen LOCK, UNLOCK, REFRESH_LOCK, GET_LOCK. Welche Adressen der Editor anbietet und mit welchen Schlüsseln er seine Aufrufe signiert, veröffentlicht er in seinem Discovery-Dokument.

Der entscheidende Punkt: Wer WOPI-Host ist, sieht das Dokument im Klartext. In einer Standardinstallation ist das Nextcloud.

---

Das Gateway als WOPI-Host

Das DuoKey-Gateway übernimmt die Rolle des WOPI-Hosts. Nextcloud bleibt Speicher und Rechteverwaltung, sieht aber nur noch Chiffrat.

Abbildung 1. Komponenten und Vertrauenszonen. Klartext existiert serverseitig nur in der Bearbeitungszone, im Arbeitsspeicher.

Das Gateway ist in Rust geschrieben und aus unabhängigen Bausteinen aufgebaut: ein Speicher-Connector (WebDAV für Nextcloud und openDesk), ein Schlüsselauflöser (das DuoKey Cockpit), ein Codec für das Dateiformat DKSF, Sitzungen, versiegelte WOPI-Tokens, Discovery und Proof-Prüfung, Sperren und ein Zugriffsjournal. Dieselben Bausteine bedienen jeden Speicher und jeden Editor.

---

Der Weg eines Dokuments, Schritt für Schritt

Abbildung 2. Öffnen, gemeinsames Bearbeiten und Speichern eines Dokuments aus einem geschützten Ordner.

1. Der Benutzer wählt in Nextcloud „Mit DuoKey öffnen“.
2. Er wird zum Gateway weitergeleitet und meldet sich per OpenID Connect an, etwa beim Keycloak von openDesk.
3. Das Gateway liest die verschlüsselte Datei per WebDAV, mit dem Token des Benutzers, also mit dessen Nextcloud-Rechten.
4. Es fragt das Cockpit nach dem Ordnerschlüssel für diesen Benutzer.
5. Das Cockpit prüft das Recht auf den Ordner und ob das Gateway aktiv ist.
6. Der Ordnerschlüssel wird im HSM durch den KEK entschlüsselt.
7. Das Cockpit versiegelt ihn für das Gateway, hybrid mit P-256 und ML-KEM-768, und protokolliert die Freigabe.
8. Das Gateway entschlüsselt die DKSF-Datei im Arbeitsspeicher.
9. Der Editor wird mit einem versiegelten WOPI-Token geöffnet.
10. Collabora ruft CheckFileInfo und GetFile auf, mit signierten Aufrufen.
11. Bei jeder Speicherung folgt PutFile.
12. Das Gateway verschlüsselt neu und schreibt mit If-Match zurück.
13. Die Ereignisse gehen gebündelt in das Zugriffsjournal des Cockpits.

---

Mehrere Bearbeiter, eine Sitzung

Jede Person, die ein Dokument öffnet, erhält ein eigenes WOPI-Token, gebunden an eine Datei und eine Sitzung, versiegelt und zeitlich begrenzt. Ihre Rechte werden einzeln geprüft. Die Kennung der Datei im WOPISrc ist ein mit Schlüssel gebildeter Hash (HMAC) des Speicherpfads: stabil, sodass alle Bearbeiter derselben Datei in derselben Collabora-Sitzung landen, und nicht umkehrbar, sodass sie den Pfad nicht verrät.

Wer nur ein Leserecht auf den Schlüssel oder nur eine Lesefreigabe in Nextcloud hat, öffnet den Editor im Nur-Lese-Modus; seine Speichervorgänge und Sperren werden abgelehnt.

---

Sicherheitsentscheidungen im Detail

---

Zwei unabhängige Prüfungen

Abbildung 3. Zwei unabhängige Prüfungen, bevor ein Dokument geöffnet wird.

Der Speicher wendet seine eigenen Rechte an, weil das Gateway ihn mit dem Token des Benutzers aufruft, und kein Dienstkonto benutzt, das jede Datei lesen könnte. Zusätzlich muss das Cockpit den Schlüssel an genau diesen Benutzer freigeben. Fällt eine der beiden Prüfungen weg, bleibt das Dokument zu. Ein Entzug des Rechts im Cockpit wirkt sofort für neue Freigaben; das Gateway verwirft die im Speicher gehaltenen Schlüssel spätestens nach wenigen Minuten.

---

Grenzen und Restrisiken

Ein ehrliches Bild gehört dazu:

• Die Bearbeitungszone sieht Klartext. Gateway und Collabora entschlüsseln im Arbeitsspeicher. Wird diese Zone kompromittiert, sind die während der Kompromittierung geöffneten Dokumente betroffen, nicht die übrigen. Im On-Premises- oder Hybridbetrieb betreibt die Organisation die Zone selbst; im SaaS (geplant) läuft sie je Kunde in einer AMD-SEV-SNP-Enklave, und das Cockpit gibt Schlüssel nur an ein attestiertes Gateway frei.
• Metadaten bleiben sichtbar. Nextcloud sieht Namen, Größen, Daten und Freigaben der Dateien. Die Verschlüsselung der Dateinamen ist geplant; Vorschauen und Suchindex gibt es in geschützten Ordnern nicht.
• Berechtigte Benutzer. Bildschirmfotos und Fotos des Bildschirms lassen sich technisch nicht verhindern; Wasserzeichen und Protokollierung schrecken ab.
• Vertrauen in das Gateway. Heute benennt das Gateway den Benutzer gegenüber dem Cockpit, beschränkt auf seinen eigenen Namensraum. Geplant ist, dass das Cockpit das OIDC-Token des Benutzers selbst prüft.

---

Kompatibilität

Collabora Online und OnlyOffice Docs veröffentlichen dasselbe Discovery-Format und dieselben Proof-Signaturen, weshalb dasselbe Gateway beide bedienen kann. Collabora veröffentlicht für viele Formate nur eine edit-Aktion; ein Benutzer mit Leserecht erhält dann diese Adresse, und der Editor öffnet im Nur-Lese-Modus, weil CheckFileInfo UserCanWrite: false zurückgibt.

Das Dateiformat ist dasselbe wie beim SecureFolder-Agenten für Windows und macOS: Eine auf dem Desktop verschlüsselte Datei öffnet sich im Browser und umgekehrt.

---

Quellen

1. Microsoft, WOPI-Protokoll (Open Specifications): CheckFileInfo, GetFile, PutFile, Sperren und Proof Keys. learn.microsoft.com
2. Collabora Online, Integrationsdokumentation (WOPI). sdk.collaboraonline.com
3. Nextcloud, Hub 10 und Ende-zu-Ende-Verschlüsselung im Browser. help.nextcloud.com
4. IETF, RFC 9334, Remote ATtestation procedureS (RATS) Architecture. rfc-editor.org
5. AMD, Secure Encrypted Virtualization (SEV-SNP). amd.com