Coédition chiffrée avec Collabora Online : comment une passerelle WOPI fonctionne avec des clés dans un HSM

Dans Nextcloud, la coédition dans le navigateur et le chiffrement de bout en bout s'excluent jusqu'ici : un éditeur comme Collabora Online a besoin du document en clair, et un dossier chiffré de bout en bout ne le lui fournit pas. Cet article présente une troisième voie, mise en œuvre par DuoKey SecureFolder : une passerelle WOPI qui ne déchiffre le document qu'en mémoire vive, tandis que Nextcloud ne stocke que du chiffré et que la clé maîtresse reste dans le HSM de l'organisation.

Il s'adresse aux architectes, administrateurs et responsables de la sécurité des communautés Nextcloud et openDesk qui veulent comprendre ce qui se passe techniquement et où se situent les limites.

---

Table des matières

1. WOPI en deux minutes
2. La passerelle comme hôte WOPI
3. Le parcours d'un document, étape par étape
4. Plusieurs éditeurs, une seule session
5. Les choix de sécurité en détail
6. Deux contrôles indépendants
7. Limites et risques résiduels
8. Compatibilité
9. Sources

---

WOPI en deux minutes

WOPI (Web Application Open Platform Interface) est le protocole par lequel un éditeur en ligne récupère un fichier depuis un stockage et l'y réécrit. Il connaît deux rôles :

• Le client WOPI est l'éditeur : Collabora Online ou OnlyOffice Docs.
• L'hôte WOPI fournit le fichier : normalement Nextcloud lui-même, avec l'application Nextcloud Office.

L'éditeur appelle pour l'essentiel quatre opérations chez l'hôte : CheckFileInfo (métadonnées et droits), GetFile (lecture du contenu), PutFile (écriture du contenu) et les opérations de verrouillage LOCK, UNLOCK, REFRESH_LOCK, GET_LOCK. Les adresses que propose l'éditeur et les clés avec lesquelles il signe ses appels sont publiées dans son document Discovery.

Le point décisif : l'hôte WOPI voit le document en clair. Dans une installation standard, c'est Nextcloud.

---

La passerelle comme hôte WOPI

La passerelle DuoKey reprend le rôle d'hôte WOPI. Nextcloud reste le stockage et la gestion des droits, mais ne voit plus que du chiffré.

Schéma 1. Composants et zones de confiance. Côté serveur, le texte en clair n'existe que dans la zone d'édition, en mémoire vive.

La passerelle est écrite en Rust et composée de briques indépendantes : un connecteur de stockage (WebDAV pour Nextcloud et openDesk), un résolveur de clés (le DuoKey Cockpit), un codec pour le format de fichier DKSF, des sessions, des jetons WOPI scellés, Discovery et vérification des preuves, des verrous et un journal d'accès. Les mêmes briques servent tout stockage et tout éditeur.

---

Le parcours d'un document, étape par étape

Schéma 2. Ouverture, coédition et enregistrement d'un document d'un dossier protégé.

1. Dans Nextcloud, l'utilisateur choisit « Ouvrir avec DuoKey ».
2. Il est redirigé vers la passerelle et s'authentifie via OpenID Connect, par exemple auprès du Keycloak d'openDesk.
3. La passerelle lit le fichier chiffré via WebDAV, avec le jeton de l'utilisateur, donc avec ses droits Nextcloud.
4. Elle demande au Cockpit la clé de dossier pour cet utilisateur.
5. Le Cockpit vérifie le droit sur le dossier et que la passerelle est active.
6. La clé de dossier est déchiffrée dans le HSM par la KEK.
7. Le Cockpit la scelle pour la passerelle, de manière hybride avec P-256 et ML-KEM-768, et consigne la libération.
8. La passerelle déchiffre le fichier DKSF en mémoire vive.
9. L'éditeur est ouvert avec un jeton WOPI scellé.
10. Collabora appelle CheckFileInfo et GetFile, avec des appels signés.
11. Chaque enregistrement donne lieu à un PutFile.
12. La passerelle rechiffre et réécrit avec If-Match.
13. Les événements sont envoyés par lots au journal d'accès du Cockpit.

---

Plusieurs éditeurs, une seule session

Chaque personne qui ouvre un document reçoit son propre jeton WOPI, lié à un fichier et à une session, scellé et limité dans le temps. Ses droits sont vérifiés individuellement. L'identifiant du fichier dans le WOPISrc est un hachage à clé (HMAC) du chemin de stockage : stable, pour que tous les éditeurs d'un même fichier se retrouvent dans la même session Collabora, et non réversible, pour qu'il ne révèle pas le chemin.

Une personne qui n'a qu'un droit de lecture sur la clé, ou qu'un partage en lecture dans Nextcloud, ouvre l'éditeur en lecture seule ; ses enregistrements et ses verrous sont refusés.

---

Les choix de sécurité en détail

---

Deux contrôles indépendants

Schéma 3. Deux contrôles indépendants avant l'ouverture d'un document.

Le stockage applique ses propres droits, car la passerelle l'appelle avec le jeton de l'utilisateur, et non avec un compte de service capable de lire n'importe quel fichier. En outre, le Cockpit doit libérer la clé pour cet utilisateur précis. Si l'un des deux contrôles échoue, le document reste fermé. Un retrait du droit dans le Cockpit prend effet immédiatement pour les nouvelles libérations ; la passerelle supprime les clés conservées en mémoire au plus tard après quelques minutes.

---

Limites et risques résiduels

Une image honnête l'impose :

• La zone d'édition voit le texte en clair. La passerelle et Collabora déchiffrent en mémoire vive. Si cette zone est compromise, les documents ouverts pendant la compromission sont touchés, pas les autres. En exploitation sur site ou hybride, l'organisation exploite elle-même la zone ; en SaaS (prévu), elle tourne par client dans une enclave AMD SEV-SNP, et le Cockpit ne libère les clés qu'à une passerelle attestée.
• Les métadonnées restent visibles. Nextcloud voit les noms, tailles, dates et partages des fichiers. Le chiffrement des noms de fichiers est prévu ; il n'y a ni aperçus ni index de recherche dans les dossiers protégés.
• Utilisateurs autorisés. Les captures d'écran et les photos de l'écran ne peuvent pas être empêchées techniquement ; le filigrane et la journalisation ont un effet dissuasif.
• Confiance dans la passerelle. Aujourd'hui, la passerelle désigne l'utilisateur auprès du Cockpit, dans les limites de son propre espace de noms. Il est prévu que le Cockpit vérifie lui-même le jeton OIDC de l'utilisateur.

---

Compatibilité

Collabora Online et OnlyOffice Docs publient le même format Discovery et les mêmes signatures de preuve, si bien que la même passerelle peut servir les deux. Pour de nombreux formats, Collabora ne publie qu'une action edit ; un utilisateur disposant d'un droit de lecture reçoit alors cette adresse, et l'éditeur s'ouvre en lecture seule, car CheckFileInfo renvoie UserCanWrite: false.

Le format de fichier est le même que celui de l'agent SecureFolder pour Windows et macOS : un fichier chiffré sur le poste de travail s'ouvre dans le navigateur, et inversement.

---

Sources

1. Microsoft, protocole WOPI (Open Specifications) : CheckFileInfo, GetFile, PutFile, verrous et proof keys. learn.microsoft.com
2. Collabora Online, documentation d'intégration (WOPI). sdk.collaboraonline.com
3. Nextcloud, Hub 10 et chiffrement de bout en bout dans le navigateur. help.nextcloud.com
4. IETF, RFC 9334, Remote ATtestation procedureS (RATS) Architecture. rfc-editor.org
5. AMD, Secure Encrypted Virtualization (SEV-SNP). amd.com