Livre blanc de sécurité

Analyse technique approfondie de la protection de vos fichiers par RocketShare grâce au chiffrement à connaissance nulle

Ce document fournit un aperçu technique complet de la façon dont RocketShare protège vos données. Il s'adresse aux professionnels de la sécurité, aux responsables de la conformité et à toute personne souhaitant comprendre exactement comment fonctionne notre chiffrement.

1. Résumé exécutif

RocketShare est une plateforme de partage de fichiers avec chiffrement à connaissance nulle. Les fichiers sont chiffrés côté client à l'aide d'AES-256-GCM avant le téléversement, et la clé de chiffrement est intégrée exclusivement dans le fragment d'URL — une partie de l'URL que les navigateurs ne transmettent jamais aux serveurs. Cette architecture signifie que les opérateurs de RocketShare ne peuvent en aucun cas accéder, lire ou déchiffrer les fichiers des utilisateurs, y compris dans le cadre de demandes d'interception légales.

Propriétés clés :

  • Architecture à connaissance nulle — le serveur ne possède jamais les clés de déchiffrement
  • Chiffrement de bout en bout — les fichiers sont chiffrés avant de quitter l'appareil de l'expéditeur et déchiffrés uniquement sur l'appareil du destinataire
  • Aucun stockage de clés côté serveur — les clés n'existent que dans le fragment d'URL du lien de partage
  • Expiration et suppression automatiques — les fichiers sont définitivement supprimés après expiration

2. Modèle de menace

Ce contre quoi nous protégeons

  • Compromission du serveur — même si un attaquant obtient un accès complet à nos serveurs, les fichiers stockés restent chiffrés et illisibles sans la clé propre au transfert
  • Interception réseau — TLS 1.3 protège les données en transit ; les clés de chiffrement dans les fragments d'URL ne sont jamais envoyées sur le réseau
  • Menaces internes — les opérateurs de RocketShare n'ont aucun accès au contenu des fichiers par conception, pas par politique
  • Interception légale — nous ne pouvons pas répondre aux demandes de déchiffrement car nous ne possédons pas les clés ; nous ne pouvons fournir que des blobs chiffrés et des métadonnées

Ce qui est hors de notre modèle de menace

  • Appareil de l'expéditeur ou du destinataire compromis — si un logiciel malveillant a accès au navigateur de l'utilisateur, il pourrait intercepter les clés ou les fichiers en clair
  • Interception du lien de partage — toute personne qui obtient le lien de partage complet (y compris le fragment d'URL) peut déchiffrer les fichiers ; les utilisateurs doivent partager les liens de manière sécurisée
  • Vulnérabilités du navigateur — nous nous appuyons sur l'API Web Crypto fournie par le navigateur ; les exploits au niveau du navigateur échappent à notre contrôle

3. Mise en œuvre du chiffrement

Algorithme

Tout chiffrement de fichiers utilise AES-256-GCM (Galois/Counter Mode), un algorithme de chiffrement authentifié symétrique. GCM assure à la fois la confidentialité et l'intégrité, ce qui signifie que toute altération du texte chiffré est détectée lors du déchiffrement.

Génération de clés

Les clés de chiffrement sont générées côté client à l'aide de l'API Web Crypto du navigateur (crypto.subtle.generateKey), qui s'appuie sur le générateur de nombres pseudoaléatoires cryptographiquement sécurisé (CSPRNG) du système d'exploitation.

  • Taille de clé : 256 bits
  • Source : API Web Crypto (crypto.subtle.generateKey), basée sur le CSPRNG au niveau du système d'exploitation
  • Portée : une clé unique par transfert (fichier ou lot)

Processus de chiffrement

  1. L'utilisateur sélectionne les fichiers à téléverser
  2. Une clé AES de 256 bits est générée à l'aide de crypto.subtle.generateKey()
  3. Un vecteur d'initialisation (IV) unique de 96 bits est généré par opération de chiffrement
  4. Les fichiers sont chiffrés dans le navigateur à l'aide d'AES-256-GCM via l'API Web Crypto
  5. Le texte chiffré est téléversé sur le serveur
  6. Le matériel de clé brute est encodé en Base64url et placé dans le fragment d'URL (#<base64url-key>)

Chiffrement en flux

Pour les fichiers volumineux, RocketShare utilise une approche de chiffrement en flux. Les fichiers sont traités par morceaux pour minimiser l'utilisation de la mémoire, permettant le chiffrement et le téléversement de fichiers qui dépassent la RAM disponible.

Chaque morceau est chiffré avec son propre IV de 96 bits généré aléatoirement (crypto.getRandomValues), garantissant un texte chiffré unique pour chaque morceau même si le contenu du fichier se répète.

4. Gestion des clés

Approche par fragment d'URL

La clé de déchiffrement est intégrée dans le fragment d'URL (la portion après #). Il s'agit de la propriété de sécurité critique du système :

  • Les navigateurs ne transmettent jamais les fragments d'URL aux serveurs dans les requêtes HTTP (RFC 3986, Section 3.5)
  • Le fragment reste entièrement côté client — dans la barre d'adresse du navigateur, l'historique et lorsqu'il est partagé par l'utilisateur
  • Le serveur ne reçoit que le chemin et les paramètres de requête, jamais la portion de clé #...

Cycle de vie des clés

  1. Génération — créée dans le navigateur de l'expéditeur à l'aide du CSPRNG
  2. Utilisation — utilisée immédiatement pour le chiffrement côté client
  3. Intégration — placée dans le fragment d'URL du lien de partage
  4. Transmission — l'utilisateur partage le lien via son canal sécurisé préféré (email, messagerie, etc.)
  5. Déchiffrement — le navigateur du destinataire lit le fragment et déchiffre le fichier
  6. Aucun stockage — les clés ne sont jamais stockées sur le serveur ; elles n'existent que dans le lien de partage

Ce que le serveur stocke

Le serveur stocke uniquement :

  • Des blobs de fichiers chiffrés (texte chiffré)
  • Des métadonnées de transfert : nom de fichier, taille de fichier, type MIME, date d'expiration
  • Des paramètres de transfert : limite de téléchargement, hash de protection par mot de passe (si activé)
  • Des données au niveau du compte : email, jetons d'authentification (non liés au chiffrement des fichiers)

Le serveur ne stocke jamais : les clés de chiffrement, le contenu des fichiers en clair ou toute donnée pouvant être utilisée pour dériver la clé.

5. Cycle de vie des fichiers

Téléversement

  1. L'utilisateur sélectionne les fichiers → la clé de chiffrement est générée côté client
  2. Les fichiers sont chiffrés avec AES-256-GCM dans le navigateur
  3. Les blobs chiffrés sont téléversés sur le serveur via TLS 1.3
  4. Le serveur stocke le texte chiffré + les métadonnées, retourne l'ID de transfert
  5. Le lien de partage est construit : https://rocketshare.app/d/{id}#{base64url-key}

Stockage

  • Les fichiers chiffrés sont stockés sur un stockage d'objets compatible S3 hébergé dans l'UE (Amsterdam)
  • Les fichiers sont stockés sous forme de blobs chiffrés opaques — le fournisseur de stockage ne peut pas les lire
  • Les métadonnées sont stockées dans PostgreSQL avec chiffrement au repos sur le volume de base de données

Téléchargement

  1. Le destinataire ouvre le lien de partage
  2. Le navigateur extrait la clé du fragment d'URL (jamais envoyée au serveur)
  3. Le blob chiffré est téléchargé depuis le serveur
  4. Le déchiffrement se produit entièrement dans le navigateur du destinataire
  5. Le fichier en clair est présenté à l'utilisateur pour téléchargement

Expiration et suppression

  • Les transferts ont une expiration configurable (3 à 90 jours selon le forfait)
  • Après expiration, une tâche de nettoyage programmée supprime définitivement les blobs chiffrés du stockage d'objets et les enregistrements de fichiers de la base de données
  • L'enregistrement des métadonnées de transfert (noms de fichiers, tailles, horodatages) est conservé dans un état expiré à des fins comptables et d'audit, mais toutes les données de fichiers chiffrés sont irréversiblement supprimées
  • Aucune sauvegarde des données de fichiers expirés n'est conservée

6. Infrastructure

Hébergement

  • Application : déployée sur Cloudflare Workers (calcul en périphérie)
  • Base de données : PostgreSQL, hébergée dans l'UE
  • Stockage d'objets : compatible S3, région UE (Amsterdam)
  • Cache : Cloudflare KV (magasin clé-valeur), pour les données de session et de limitation de débit uniquement — jamais utilisé pour le contenu des fichiers
  • CDN : réseau mondial Cloudflare pour les ressources statiques et le routage en périphérie

Résidence des données

Tous les serveurs de stockage de fichiers et de bases de données sont situés au sein de l'Union européenne. Nous ne répliquons pas les données de fichiers en dehors de l'UE.

Sécurité réseau

  • TLS 1.3 imposé sur toutes les connexions (HTTP et base de données)
  • HSTS avec préchargement — les navigateurs sont instruits de toujours utiliser HTTPS
  • En-têtes de sécurité HTTP — CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy
  • Aucun contenu mixte — toutes les ressources chargées via HTTPS

7. Authentification et contrôle d'accès

Authentification des utilisateurs

  • Email/mot de passe — mots de passe hachés avec scrypt (N=16384, r=16, p=1), longueur minimale de 8 caractères imposée
  • OAuth — SSO Google et Microsoft via OAuth 2.0 / OpenID Connect, conformes aux standards de l'industrie
  • Gestion de session — cookies HTTP-only sécurisés avec attributs SameSite appropriés

Contrôles d'accès aux transferts

  • Accès basé sur le lien — toute personne disposant du lien de partage complet peut déchiffrer (la clé est dans l'URL)
  • Protection par mot de passe optionnelle — les transferts peuvent nécessiter un mot de passe supplémentaire ; le hash du mot de passe est vérifié côté serveur avant de livrer le blob chiffré
  • Limites de téléchargement — nombre maximum configurable de téléchargements avant que le lien ne soit désactivé
  • Expiration — expiration automatique basée sur le temps après laquelle les données de fichiers chiffrés sont définitivement supprimées

8. Minimisation et conservation des données

Principe de minimisation des données

Nous ne collectons que ce qui est nécessaire au fonctionnement du service :

  • Données de compte : adresse email, nom (si fourni via OAuth), mot de passe haché
  • Métadonnées de transfert : noms de fichiers, tailles, types MIME, horodatages, dates d'expiration
  • Données d'utilisation : nombre de transferts et stockage utilisé (pour l'application des forfaits)
  • Analytique : modèles d'utilisation anonymisés via PostHog (hébergé dans l'UE, configuration axée sur la confidentialité)

Ce que nous ne collectons pas

  • Le contenu des fichiers (nous ne pouvons pas accéder aux blobs chiffrés)
  • Les clés de chiffrement
  • Les adresses IP dans le stockage à long terme (les journaux d'accès sont éphémères)
  • L'historique de navigation ou les données de suivi intersites

Conservation

  • Transferts : données de fichiers chiffrés supprimées automatiquement à l'expiration ; métadonnées de transfert conservées dans un état expiré
  • Données de compte : conservées tant que le compte est actif ; supprimées sur demande de suppression de compte
  • Journaux d'accès : éphémères, non persistés au-delà du cycle de vie de la requête

9. Réponse aux incidents

En cas d'incident de sécurité :

  1. Confinement — isoler immédiatement les systèmes affectés
  2. Évaluation — déterminer la portée et l'impact ; grâce à l'architecture à connaissance nulle, une violation de serveur n'expose pas le contenu des fichiers
  3. Notification — les utilisateurs affectés sont notifiés dans les 72 heures comme l'exige le RGPD
  4. Remédiation — corriger la cause première, améliorer les défenses
  5. Divulgation — divulgation publique de l'incident et de notre réponse

Les problèmes de sécurité peuvent nous être signalés via notre politique de Divulgation responsable.

10. Limites et transparence

Nous croyons en la transparence sur ce que notre architecture de sécurité protège et ne protège pas :

  • Nous ne pouvons pas récupérer les liens perdus — si un utilisateur perd le lien de partage (y compris le fragment d'URL), les fichiers chiffrés ne peuvent pas être déchiffrés. Nous n'avons pas la clé.
  • La sécurité du lien est la responsabilité de l'utilisateur — le lien de partage est le seul identifiant d'accès. S'il est intercepté (par exemple, envoyé via un canal non sécurisé), l'intercepteur peut déchiffrer les fichiers.
  • CSP avec politique de script basée sur nonce — nous utilisons une Content Security Policy avec strict-dynamic et des sources de script basées sur nonce, ce qui est l'approche recommandée pour les applications SSR. Les styles en ligne nécessitent toujours unsafe-inline en raison de Tailwind CSS.
  • Confiance dans le navigateur — notre chiffrement repose sur l'API Web Crypto. Si le navigateur est compromis, toutes les garanties tombent.
  • Visibilité des métadonnées — bien que le contenu des fichiers soit chiffré, les noms de fichiers, tailles et horodatages sont visibles par le serveur à des fins opérationnelles.

Ce livre blanc est à jour en février 2026. Nous mettons à jour ce document lorsque notre architecture de sécurité change. Pour toute question, contactez-nous.