Sécurité de PrivCloud

Vue d'ensemble

PrivCloud est conçu selon le principe du zero-knowledge. Le chiffrement de bout en bout est le mode par défaut de tout compte : la clé de déchiffrement reste dans le fragment d'URL et n'est pas transmise au serveur, si bien que ni notre équipe ni notre fournisseur de stockage ne peuvent lire le contenu de vos fichiers. Elle ne passe par nos serveurs que si vous choisissez de l'envoyer par e-mail. Le chiffrement est effectué dans votre navigateur, avant même que vos données ne quittent votre appareil. Cette page décrit de manière transparente les mécanismes cryptographiques, les choix d'infrastructure et les limites honnêtes du système.

Comment ça fonctionne

• Une clé AES-256 est générée localement dans votre navigateur via l'API Web Crypto.
• Vos fichiers sont chiffrés côté client avant l'upload -- nous ne recevons que du texte chiffré opaque.
• La clé de déchiffrement est intégrée dans le lien de partage sous la forme d'un fragment d'URL (#key=...). Le protocole HTTP prévoit que le navigateur n'envoie pas ce fragment au serveur : il reste sur votre appareil et n'apparaît dans aucun log de notre infrastructure.
• Le destinataire déchiffre directement dans son navigateur. Par défaut, la clé ne transite pas par notre infrastructure : elle n'y passe que si vous choisissez de l'envoyer par e-mail.

Algorithmes utilisés

L'architecture zero-knowledge signifie que notre système est conçu pour que nous ne puissions pas accéder au contenu de vos fichiers chiffrés de bout en bout, même si nous le voulions ou si nous y étions contraints : par défaut, la clé n'est pas transmise à nos serveurs. Elle n'y passe que si vous choisissez de l'envoyer par e-mail.

• Les fichiers de votre compte sont chiffrés avant l'upload
• Par défaut, votre clé ne transite pas par nos serveurs
• Nos logs ne contiennent aucune clé de déchiffrement
• Même un accès complet à notre base de données ne permettrait pas de lire vos fichiers

Ce que notre serveur voit

Le chiffrement de bout en bout protège le contenu. Pour fonctionner, le service conserve en revanche ces informations lisibles :

• votre adresse e-mail, votre nom d'utilisateur, les adresses des destinataires et la composition de vos équipes
• la taille, le nombre et les dates des fichiers, ainsi que les adresses IP de connexion
• les libellés des partages créés sans chiffrement de bout en bout
• le nom des équipes, de leurs dossiers et des documents soumis à signature

Le partage de secret de Shamir sert uniquement à récupérer votre clé E2E si vous la perdez. Il est facultatif : sans fragments ni coffre passkey, une clé perdue rend vos fichiers chiffrés définitivement illisibles, et PrivCloud ne peut pas la retrouver à votre place. PrivCloud utilise sa propre implémentation, exécutée entièrement dans votre navigateur : les fragments sont affichés sur votre écran et ne sont pas envoyés au serveur.

Principe

À la création, vous choisissez le nombre de fragments et le seuil nécessaire pour reconstituer la clé (par exemple 3 fragments dont 2 suffisent). Avec moins de fragments que ce seuil, il est mathématiquement impossible de retrouver la clé : ils ne révèlent rien d'elle.

Pourquoi c'est important

• Expiration automatique : chaque lien a une durée de vie configurable. Passé ce délai, le lien est révoqué et les fichiers supprimés.
• Protection par mot de passe : ajoutez une couche d'authentification supplémentaire sur chaque partage.
• Limite de téléchargements : définissez un nombre maximum de téléchargements autorisés par lien. Passé ce seuil, le lien est automatiquement révoqué.
• Notifications de téléchargement : soyez alerté en temps réel lorsqu'un destinataire télécharge votre fichier, afin de détecter tout accès non anticipé. Note : si vous disposez de l'option de prévisualisation et que vous souhaiteriez également recevoir une notification lors de ce type de consultation, n'hésitez pas à nous en faire part directement via le dépôt GitHub.

Une passkey utilise une clé cryptographique gérée par un authentificateur, éventuellement synchronisée selon le fournisseur. Avec le plan Team, elle sert aussi à approuver une remise de copie à un prestataire externe, avec des preuves vérifiables et des limites documentées.

• Connexion par passkey : WebAuthn avec vérification de l'utilisateur (code, empreinte ou visage). L'ajout d'une passkey exige le mot de passe ou une reconnexion par le fournisseur lié, plus le code 2FA s'il est actif, et vous en êtes averti par e-mail.
• Copie en consultation seule : le prestataire reçoit des images de pages filigranées, chiffrées pour lui seul. Ni le fichier original ni la clé d'équipe ne lui sont jamais servis.
• Remise validée et horodatée : la passkey de l'administrateur lie l'approbation au manifeste des pages. L'horodatage RFC 3161 porte sur une empreinte. Vérifier la chaîne avec une racine indépendante ne suffit pas à établir le statut qualifié historique du service.
• Journal de consultation chaîné : les demandes autorisées sont journalisées avant l'envoi des pages, sans prouver une lecture humaine. Un checkpoint conservé hors de l'application avant un incident permet de comparer la partie ancrée, pas les événements jamais enregistrés ni la fin non ancrée.
• Marquage invisible : chaque copie porte un motif pour rechercher une copie émise compatible. Recadrage, recompression et autres modifications peuvent empêcher sa détection. Une correspondance ne désigne pas la personne responsable. L'équipe conserve localement la clé du motif.
• Preuves conservées trois ans : le registre et le journal sont conservés techniquement trois ans et exportables depuis le coffre-fort ouvert par passkey. Le vérificateur hors ligne distingue les dossiers valides, invalides et indéterminés. Cette durée n'est pas une justification juridique automatique. Le titre et le contenu du document ne figurent pas dans ce registre.

• N'importe quel chercheur en sécurité peut auditer notre code
• Les implémentations cryptographiques sont vérifiables publiquement
• Aucune backdoor ne peut être dissimulée sans être détectée par la communauté
• La transparence est structurelle, pas marketing

Si vous êtes chercheur en sécurité ou auditeur et souhaitez réaliser une revue de code formelle, nous sommes ouverts à toute démarche d'audit indépendant. Contactez-nous via le dépôt GitHub.

Vous avez découvert une faille de sécurité ? Nous vous encourageons à nous la divulguer de manière responsable.

Contact : security@stockageprive.net ou via une issue privée sur le dépôt GitHub.

• Accuser réception sous 48h
• Vous tenir informé des corrections apportées
• Mentionner votre contribution (si vous le souhaitez) dans notre hall of fame

Règles de test et traitement des données

• Testez uniquement avec vos propres comptes et vos propres données.
• Sont interdits : déni de service, spam, ingénierie sociale, brute force massif et tests destructifs.
• Si une faille donne accidentellement accès aux données d'un tiers, arrêtez immédiatement le test et signalez-la sans approfondir ni conserver, modifier ou partager ces données.

Vérification publique du partage en lecture seule

Consultez le format des preuves, les tests reproductibles et les résultats mesurés du watermark, y compris ses limites et ses échecs.

Consulter les tests et télécharger les outils